Every successful IT Transformation includes a cutover – a moment where the old way of doing things disappears and the new solution goes live. The right one for your enterprise depends on the amount of time you can shut down operation of the old system, your aversion to risk, the business need of a speedy transformation, and more. Here, we introduce the basic types of cutover and a few benefits and risks associated with each one.
Big Bang
Explained:
A big bang approach will transform your enterprise overnight. With this cutover type, you turn off the legacy system, extract and transform data for all modules, and load to the target system. When the rest of the business arrives for work the next day, the legacy system is retired (retained only for history) and the new system is live.
Benefits:
Going big means you can capitalize on your investment earlier. When the entire company moves to the new system (ERP, HCM, PLM, etc.) you immediately have better data governance, a higher level of automation, and greater integration of departments across your enterprise.
Big Bang is the cleanest approach because no custom interfaces between the legacy and target systems need to be built. Likewise, there are no dual maintenance activities across the legacy and target system.
Psychologically, big bang is the most powerful. The entire enterprise (not just a few departments at a time) are aligned towards a goal, and when cutover begins, it is like watching a rocket launch.
Warnings:
This approach has the longest cutover window. For example, this is not feasible for hospitals or companies that ship every hour of every day (think Amazon). Also, the workforce needs to be prepared – that means heavy investment in training on the new system long before cutover since there is no intermediary phase where users can rely on the legacy system.
Phased by Business Unit
Explained:
Phasing by business unit means having separate parts of your company implement the new solution one after another. This means multiple smaller rollouts, each one including all modules of the new ERP but limited to one business unit.
Benefits:
Phasing rollouts by business unit allow your enterprise to have a pilot program for the new ERP. This pilot program can be used to prove out the solution (important if you are an early adopter of the new system) or provide training across the enterprise.
For a company that grows by acquisition, phasing rollout by business unit is an obvious choice. Lessons learned in the first implementations enable smoother implementation and better planning for later implementations.
Warnings:
It is likely that some data exists across business and will require dual maintenance. If you are a university, this could be a professor who works at multiple campuses. If you are a manufacturer, it could be a finished good that is produced at multiple plants.
By necessity, phased rollouts require more time. No matter how strong your project management skills are, you will still need separate integration test cycles and quality assurance for every phase. These integration cycles add weeks and months to your overall schedule.
Phased by Module
Explained:
Phasing by module means having different functional areas migrated to the new system at a time. For example, Financials can be brought over to the new ERP, followed by Manufacturing, followed by Human Resources.
Benefits:
Phasing your implementation this way allows you to go-live with relatively straightforward modules first. For example, your company could have a heavily customized legacy solution for manufacturing but straightforward financials. In this case, architecture and configuration for Finance can be completed long before Manufacturing so implementing Finance early makes sense.
Warnings:
Many of the same drawback from Big Bang apply here, albeit limited to module.
Some level of integration between the legacy and target systems need to be built, but since this is only across modules (not within modules) integration is less significant than if it was Phased by Business Unit.
Big Bang Plus Delta
Explained:
This approach has a large amount of data weeks ahead of the actual cutover, then a smaller delta conversion occurs during cutover. Typically, this means that higher volume master data is migrated early making a shorter cutover window possible. The true cutover would then handle updates and additions to the previously converted data. Smaller master data sets and open transactions (such as Open Sales Orders) would be handled exactly one time at cutover.
Benefits:
Migrating master data early makes timing less of a concern. The validation teams can be given enough time to audit converted data without delaying the schedule. This approach enables large enterprises to have shorter cutover windows than if they attempted a true Big Bang cutover.
Warnings:
Migrating data into the new environment early (before go-live) means that dual-maintenance is required between the old and new system. Consequently, a manual effort or more complex automated conversion programs are needed to ensure data integrity is maintained between the initial conversion and go-live.
