6.2Migration approaches and planning

Migrating to a new system requires as much design attention on the migration itself as on feature development. A systems architect must choose the migration approach (big-bang, phased, or parallel) based on constraints such as the downtime the business can tolerate, risk appetite, and budget, and build a migration plan that includes a rollback procedure to safely revert if it fails. Getting the migration-approach choice wrong lets a failed cutover cause direct business damage.

6.2.1Big-bang, phased, and parallel migration

• Big-bang migration stops the old system on a set date and switches over to the new one all at once. It has the advantage of a short migration period and no cost or complexity from maintaining both systems simultaneously, but it is a high-risk, high-reward approach: if a problem surfaces right after cutover, the entire business is affected, and rollback is also difficult.
• Phased migration splits the target (by site, department, function, etc.) and switches over to the new system one portion at a time. Even if a problem occurs, its impact can be contained, and lessons learned in early stages can be fed into later ones, so risk is low—but old and new systems coexist for an extended period, incurring the cost of building and maintaining an interim link (data synchronization, etc.) between them.
• Parallel migration runs both the old and new systems live simultaneously for a set period, cross-checking their outputs to verify the new system's correctness before stopping the old one. It is the safest, lowest-risk approach, but the cost of operating the same processing twice (staffing, infrastructure) is the highest. It is often chosen for core systems in finance, accounting, and similar domains where errors cannot be tolerated.

6.2.2Data migration, rehearsal, rollback, and go/no-go

• Data migration proceeds through extraction, then conversion (absorbing differences in data format and code schemes between old and new), then loading into the new system, then verifying record counts and consistency. In particular, errors in the conversion logic tend to surface as business-data inconsistencies only after the migration, so prior verification using test data close to production data is essential.
• Rehearsal trials the migration work itself in advance, using the same procedure and a comparable data volume as the actual cutover, to gauge how long it will take and to surface gaps in the procedure. Rollback is the procedure for safely reverting to the old system if a fatal problem surfaces after migration; it is important to decide in advance how much time is available for a rollback decision (a decision deadline), since rollback becomes difficult once too much new data has been written to the new system.
• Go/no-go decision: the final call, made just before cutover, on whether to proceed with the cutover as scheduled or postpone it, based on rehearsal results, data-verification results, and the readiness of the relevant departments. Documenting the decision criteria (what must be satisfied for a "go") in advance avoids an ad hoc judgment call on the day.

Suppose a systems architect is planning the migration of a payment core system that must run 24/7/365 to a new system. When first weighing the migration approach, big-bang migration is ruled out because, if a problem surfaces right after cutover, the risk of a total outage of the business's lifeline—payments—is too great. Phased migration is also judged inappropriate, because splitting payment processing so only some transactions move to the new system is impractical from a business standpoint (maintaining transaction consistency requires processing everything through the same system). In the end, the architect chooses parallel migration, running both old and new systems simultaneously for a set period, feeding identical transactions into both and cross-checking the results—because although the dual-operation cost is high, this is the safest choice in a domain like payments where errors cannot be tolerated. For the migration plan, the architect runs a rehearsal with a production-equivalent data volume one month before cutover, discovers that data conversion takes longer than expected, and adds an improvement to split the conversion into batches run in parallel. For cutover day, the architect sets in advance a decision criterion (a rollback deadline)—if verification is not complete within two hours of loading data into the new system, roll back—and schedules a go/no-go decision meeting, attended by representatives from management, the business side, and the development team, right before cutover, establishing a process to make the final call based on the rehearsal and data-verification results. Choosing the migration approach based on the risk and downtime the business can tolerate, and planning the rehearsal, rollback criteria, and go/no-go decision together as one whole, is what the practice looks like.

6.2.3Section summary

• Big-bang = short but high-risk, phased = limits impact but raises coexistence cost, parallel = safest but highest dual-operation cost
• Data migration follows extract, convert, load, verify; rehearsal with production-equivalent data verifies the procedure and timing in advance
• Decide the rollback decision deadline in advance, and document go/no-go criteria to avoid an ad hoc call on the day