An IPMI-to-Redfish migration is now a priority on the agenda for many data centers. In June 2020, the IPMI promoters—which include Dell, HPE, NEC, and Intel—announced that there would be no further updates to the IPMI standard and that Redfish is its successor (DMTF, 2020).
IPMI has not been developed further since 2020; its successor is Redfish, based on REST and JSON. The Redfish migration runs in four phases: an inventory of Redfish capability, parallel operation of both protocols, step-by-step migration of the automation, and switching IPMI off only where the migration runs stably.
Why Redfish Is Considered the Successor to IPMI
IPMI, which has been in use since the late 1990s, was a step forward for its time. It provided a standard for remote access to server hardware that worked across different manufacturers. The DMTF, the standards body behind both protocols, describes IPMI’s central weakness as follows: It is designed around the lowest common denominator (DMTF, 2018). Features that were not supported equally by every manufacturer were either left out or retrofitted as proprietary solutions.
| Characteristic | IPMI | Redfish |
|---|---|---|
| Further Development | Discontinued since 2020 | Ongoing; latest version 2025.2 |
| Technical Basis | binary protocol | REST and JSON |
| Tools | Requires a dedicated IPMI toolset | Standard tools, such as curl |
| Features | least common denominator | Standardized schemas for all manufacturers |
| Firmware Update Service | proprietary to each manufacturer | Standardized since version 2016.2 |
Since version 1.0 in August 2015, Redfish has relied on REST and JSON instead of a binary protocol (DMTF, 2017). At first glance, this may sound like a technical detail, but it has practical implications. A curl request to a Redfish interface returns a human-readable JSON response that can be processed directly. The same query via IPMI often requires a special command-line tool and an understanding of binary return codes, which can vary slightly depending on the manufacturer.
What Redfish Has Gained Since Its First Version
The standard has been continuously expanded since 2015. With version 2016.2, firmware update services were standardized for the first time, making them accessible via the same interface (DMTF) across all supporting manufacturers. Version 2020.4 added, among other things, power and thermal management as well as dedicated AccountTypes for KVMIP and Virtual Media—that is, precisely the functions needed for remote access to server consoles (DMTF, 2020).
This does not mark the end of the development process. According to the DMTF newsletter from August 2025, version 2025.2 alone introduced eight new schemas and 36 updates to existing schemas. Anyone who migrates is therefore switching to a standard that continues to evolve.
The Redfish Migration in Four Phases
- Inventory. Which servers in the current inventory already support Redfish natively, which ones only support it via an optional firmware update, and which ones don't support it at all? This inventory check will determine the entire timeline moving forward and should not be skipped, no matter how unspectacular it may sound.
- Parallel operation. New automation scripts are written and tested using Redfish, while production operations continue to be supported via IPMI. This parallel operation is at the heart of any low-risk Redfish migration.
- A phased transition. Monitoring, firmware rollouts, and provisioning scripts are gradually shifting from IPMI calls to Redfish endpoints, one server group at a time rather than all at once.
- Shutdown. IPMI will be disabled only for those servers where the migration has been fully completed and has been running stably for an extended period of time.
Inventory of Your Fleet's Redfish CapabilityWe'll determine which of your servers support Redfish natively, which ones need a firmware update, and which ones will continue to use IPMI.
Tools for the Transition
For practical implementation, what counts is which tools are already in place in your own operation and speak Redfish. Many automation and management tools now support the standard directly, often alongside the existing IPMI connection. KVM Fleet, too, relies on Redfish for newer servers, in order to query firmware versions and system information consistently across the entire fleet without needing a separate custom solution for each manufacturer. How firmware updates can be organized beyond that is described in the article on Firmware Updates via Hundreds of Servers. The architectural question behind it is covered in the article on KVM-over-IP at a fleet-wide scale.
Frequently Asked Questions
Can IPMI and Redfish run in parallel in the same environment?
Yes, that is actually the standard approach. Most modern BMCs support both protocols simultaneously, so existing IPMI scripts can continue to run while new automation is gradually migrated to Redfish. A hard switch on a single deadline is rarely necessary and, in practice, not recommended.
What happens to old servers that don't support Redfish?
Servers without a Redfish-capable BMC will continue to rely on IPMI for as long as they remain in use. Replacing them solely because of the protocol is rarely cost-effective; the deciding factor is usually when the hardware reaches the end of its useful life.
Which management tools already support Redfish?
Major server manufacturers offer their own Redfish-compatible tools for their platforms, supplemented by management solutions that support the standard across multiple manufacturers. Before migrating to Redfish, it’s worth taking a look at your own toolchain to determine which components already support Redfish and where an update is still needed.
The Next Step
KVM Fleet was developed in-house at torck and already supports Redfish on newer servers because the team went through the transition process itself in its own operations. Some of the software's features were developed directly as a result of this Redfish migration. Learn more at the Product Page for KVM Fleet.
German 
English 
French