The four data migration strategies, side by side
Each of the four is described below in the same order: what it is, what it costs you, where it fits, and who should not pick it. Read them as a set rather than one at a time, because the differences matter more than the descriptions.
Big bang migration
What it is. You freeze the old system, move everything, check it, and open the new system. One window, one source of truth, no overlap, and most big bang cutovers are scheduled across a weekend or a public holiday, because that is the longest quiet period a business gets for free.
What it costs you. Downtime, and a hard deadline: the window is fixed by the business, not by the migration, so the extract and load have to finish inside it with time to spare for verification. That spare time is the part teams cut when they are late, and it is the one part that should never be cut. A big bang is also the cheapest of the four to run, because there is only ever one live system and one set of numbers.
Where it fits. Datasets you can move and verify well inside the window, systems with a genuine quiet period, and projects where running two systems side by side would confuse the business more than a short outage would.
Who should not pick it. Anybody who cannot state the size of their own dataset, or who has never timed a full load end to end. A big bang with an untested duration is not a strategy but a bet.
Phased migration
What it is. You move one slice at a time, and each slice goes live before the next one starts. The slice can be a business unit, a region, a product line, or a module, and both systems run until the last slice lands.
What it costs you. Integration work that a big bang never needs. While the two systems coexist, records have to flow between them, and that temporary plumbing is real engineering with real testing. Expect to build interfaces you will throw away. The second cost is time: a phased move stretches over months, and people lose interest in a project long before it finishes.
Where it fits. Large estates where one window could never hold everything, businesses that cannot accept a long outage, and programmes that want to learn from the first slice before committing the rest, which is the strongest argument for this approach.
Who should not pick it. Teams without the capacity to run the temporary interfaces, and businesses whose processes cut across the slices so tightly that no clean boundary exists. If an order routinely touches three of your proposed slices, your slices are wrong.
Parallel run
What it is. Both systems process the same work for a set period, and you compare the outputs. Payroll is the classic case: run the old and the new for two cycles, check that every payslip matches, and only then switch off the old one.
What it costs you. Double entry, or double processing, for the length of the run. Somebody keys the same transaction twice, or you build a feed that copies it, and either way the cost is real and visible to the people doing it. The run also needs an owner who compares the two outputs line by line and records the differences. A parallel run with nobody comparing is just two systems and a hope.
Where it fits. Anywhere a wrong number has consequences you cannot walk back — payroll, tax, statutory reporting, regulated calculations. It is the only one of the four that gives you evidence rather than confidence, because you have two answers to the same question and you can see whether they agree.
Who should not pick it. Any process where duplicating the work is impossible, such as physical dispatch or anything that sends a message to a customer, since you cannot ship the same pallet twice to prove the new warehouse system works.
Trickle migration
What it is. Data moves continuously while both systems stay live, usually through change data capture or a synchronisation layer. The old system keeps working, the new one fills up behind it, and the switch happens once the gap is small enough to close in minutes.
What it costs you. The most engineering of the four, and the most operational care, because you now own a pipeline that has to stay healthy for weeks, handle records that change on both sides, and decide which side wins a conflict. That conflict rule is a business decision, not a technical one, and it has to be written down before the pipeline starts.
Where it fits. High-volume systems that genuinely cannot stop, where the dataset is too large for any window, and where the team has the skills to run streaming infrastructure. It pairs well with estates already built on modern data platforms, which is often the case where big data is transforming business operations day to day.
Who should not pick it. Teams whose reason for choosing it is "zero downtime" without anyone having costed the pipeline. Trickle does not remove risk; it moves the risk from one weekend into every day of the sync, which is fine if you monitor it and a slow disaster if you do not.
