A new application can be technically ready without the company being ready to switch. Data must be migrated, users trained, integrations synchronized, and incidents addressed. The transition strategy is therefore a product in its own right, with its architecture, tests, and success criteria.
Two approaches dominate the discussions. The big bang switch replaces the old system on a given date. The progressive migration moves functions, populations, or flows in stages. Neither is superior in absolute terms. The choice depends on the possibility of coexistence, the quality of the data, and the tolerance for interruption.
What a big bang switch really means
The big bang concentrates the migration within a defined window. The old system is stopped or set to read-only, the final data are transferred, checks are performed, and then the new one becomes the reference.
This strategy simplifies governance after the switch: a single application, a single source of truth, and less temporary synchronization. It is suitable when the scope is compact, the interruption is acceptable, the data can be migrated quickly, and a credible rollback exists.
Its risk comes from concentration. A transformation error, an underestimated volume, or a missing integration immediately affects all users. General rehearsals and the quality of the fallback plan become essential.
What a gradual migration covers
The gradual migration can take several forms:
- by population: a site, a subsidiary, or a pilot group;
- by capacity: research, billing, reporting, or document management;
- by pathway: new requests in the new system, history in the old one;
- by data: categories or periods transferred in waves;
- by traffic: an increasing portion of requests routed to the new component.
This approach reduces the impact radius and allows for learning. It does, however, require managing coexistence: synchronization, double entries, identity, support, reporting, and data responsibility.
The seven decision criteria
1. Tolerance to interruption
If the business can stop the system during a known window, the big bang is still possible. If every minute has a significant impact, a gradual transition or an active-active architecture must be considered.
2. Ability to segment
A gradual migration requires a boundary: users, functions, countries, products, or flows. Without a clear separation, the temporary system can become more complex than the redesign itself.
3. Source of truth
During coexistence, each piece of data must have an owner. Uncontrolled duplicate entries create divergences that are difficult to reconcile. A strategy must specify who can modify what, where, and until when.
4. Volume and quality of data
The data must be profiled before the decision. A high volume does not prevent a big bang if the transformation is fast and tested. Inconsistent data can on the contrary require a gradual migration with business correction.
5. Number of integrations
Each partner must be migrated, duplicated, or adapted. A global switch can simplify the contract, but increases the number of dependencies to coordinate on the same day.
6. Backward compatibility
Rollback does not only mean restarting the old application. It is necessary to restore the data created during the window and handle the operations sent to third parties. The more the new system writes, the more the rollback becomes a project.
7. Availability of business teams
A wave migration requires several processes, training sessions, and support periods. The big bang approach demands a concentrated strong mobilization. The choice must reflect the organization's actual capacity.
Compare the approaches
| Criterion | Big bang | Progressive migration |
|---|---|---|
| Duration of coexistence | Short | Medium to long |
| Temporary complexity | Limited but intense | Raised and distributed |
| Impact radius | Global | Limited by wave |
| Learning in production | Weak before switching | Important |
| Synchronization | Often punctual | Often continues |
| Job mobilization | Concentrated | Repeated |
| Go back | Simple only before writings | Possible by perimeter, but needs to be designed |
The scheme begins with business continuity. An acceptable interruption, a compact scope, repeated data migration, and a credible rollback make a big bang switch feasible. When the interruption is not acceptable, the ability to segment points toward a progressive migration. A representative population allows a pilot; isolatable modules allow migration by function or by traffic; a breakdown by site, subsidiary, period, or data category allows migration in waves. When segmentation is not possible, one must first reduce the scope or explicitly design coexistence and its synchronization. In all cases, the absence of proof on the data or the rollback requires repetition before the decision. The following list constitutes an equivalent textual version.
- Check if a business interruption is acceptable and bounded.
- If yes, confirm that the scope is compact, the migration repeatable, and the rollback tested before opting for a big bang.
- If not, search for a boundary by population, function, journey, data, or traffic.
- If this border exists, choose a pilot or a gradual migration in waves.
- If it does not exist, first reduce the scope or design a coexistence with an explicit source of truth.
- In each scenario, collect evidence on data, integrations, synchronization, and rollback before the go/no-go.
Design a transition architecture
A gradual migration requires explicit temporary components: router, API facade, synchronization, event log, adapters, and reconciliation screens. Each must have an owner, observability, and a retirement date.
The anti-pattern consists of adding gateways without reducing the old scope. Complexity then increases with each wave. A useful indicator tracks the share of functions, data, and traffic actually removed from the old system.
Prepare the data
Migration begins with profiling: volumes, duplicates, missing values, encoding, attachments, relationships, and retention rules. Transformations must be versioned and replayable. Checks compare totals, samples, constraints, and business results.
A full rehearsal on a realistic copy measures the time and reveals the manual operations. The final window must include a margin, decision points, and a threshold beyond which the toggle is canceled.
Define go/no-go criteria
The decision cannot be based on a general impression. The criteria include:
- zero critical anomaly open;
- validated critical paths;
- performance measured against the expected volume;
- backup and restore tested;
- confirmed integrations;
- support and communication ready;
- repeated fallback plan;
- assigned crisis responsibilities.
Each criterion has evidence, an owner, and a decision deadline.
Organize the pilot
A useful pilot is representative without being vital. It must test the real flows, permissions, data, and support. Feedback is classified between product defect, lack of training, incorrect data, and incomplete procedure.
The pilot must not become a permanent parallel version. The rollout date and the stop conditions must be defined from the start.
Prepare the switching day
The runbook describes the steps minute by minute: freezing, extraction, transformation, loading, checks, opening, monitoring, and communication. It specifies the commands, expected evidence, responsible parties, and decision points.
A crisis channel separate from the regular support centralizes the information. The technical, business, infrastructure teams and partners have a common language there and a clear decision-making authority.
Stabilize after launch
The first hours follow specific indicators: errors, queues, response times, volumes, data discrepancies, and support requests. Non-essential changes are limited until the end of the hypercare period.
The feedback must document the gaps between the plan and reality. It improves the following waves or the next projects, instead of disappearing once the pressure has subsided.
Choose the risk that one knows how to control
The big bang reduces the complexity of coexistence but concentrates the impact. Progressive migration limits each wave but adds temporary architecture. The right decision is the one whose risks can be tested, observed, and reversed.
Partitech supports the technical design, testing, and deployment of complex platforms. We integrate the transition strategy from the architecture stage so that the overhaul does not become a gamble on the day of the switch.
To deepen the approach, define a trajectory for modernize a legacy application without rewriting everything, get them ready version upgrades without interruption and frame it PRA, the BCP and business continuity. Also see Partitech services.
Official references
References checked on August 17, 2026: