A data migration is not really a technical job. Moving bytes is the easy part, and a competent engineer can write the extract and the load in a week. The hard part is the decision you make before any of that: how much of the business stops, for how long, and what happens if the new system is wrong on Monday morning.
There are four data migration strategies in common use, and only four: big bang, phased, parallel run, and trickle. Everything else is a variation on one of them, or a blend of two, and each one trades the same three things against each other — downtime, cost, and the risk of carrying bad records into a system nobody can reverse out of.
This page does three things. It explains what each of the four strategies actually costs you, in hours and in work rather than in adjectives. It gives you five questions that pick between them, so the choice comes from your own constraints and not from a vendor's preference. And it covers the part most data migration plans skip: proving that what arrived equals what left, and deciding in advance at what point you stop and go back.
We have run these moves for finance systems, ERP replacements, and warehouse consolidations. The pattern that separates a quiet cutover from a bad weekend is never the tooling, but whether somebody wrote down the reconciliation rule and the rollback trigger before the first record moved.
The decision that decides the project
Before you compare data migration strategies, settle one thing: will the old system and the new system both hold live data at the same time, and if so, for how long?
That single answer splits the four approaches in half. Big bang says no, because there is one source of truth, and it changes hands during a window when nobody is working. Phased, parallel run, and trickle all say yes, for some period, and that yes brings a cost that no plan can remove. Two live systems mean two sets of numbers, and somebody has to keep them agreeing.
That somebody is usually the business, not IT. If orders are taken in the old system on Tuesday and in the new one on Wednesday, then month-end reporting has to stitch both together. Nobody in finance signed up for that, so they need to hear about it early rather than discover it in a close.
The second thing to settle is who owns the records. Not who administers the database, but who decides that a duplicate supplier is a duplicate, and which of the two spellings survives. A migration surfaces every disagreement about master data that your organisation has been quietly living with, and it surfaces all of them in the same fortnight. Good data management and governance is what makes those calls quick instead of political, and it is far cheaper to have in place before the project than to invent during it.
Everything after this point is downstream of those two answers.
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
Five questions that pick your data migration strategy
Answer these five in order. By the fifth, one approach will usually be obvious, and the ones that are wrong for you will be clearly wrong.
How long can the business actually stop?
Ask the people who would be standing idle, not the project sponsor, and get the answer in hours, with a date attached. Find out what the real ceiling is rather than the comfortable one. A business that can genuinely lose a weekend has options that a 24-hour operation does not, and if the honest answer is "a few minutes," big bang is out, and trickle is probably in.
How much data is there, and how long does one full load take?
Run a timed load on a copy before you choose anything. Volume on its own tells you little, because a hundred million simple rows can move faster than a few million rows that need lookups, validation, and transformation on the way through. What you need is a measured duration from a real run, and then you compare that duration against the window from question one. If the load does not fit with room to verify afterwards, the window is not the problem: the strategy is.
Is the schema changing, or only the address?
A lift-and-shift to the same structure is a different job from a move into a new model, and pretending otherwise is how migrations quietly overrun. When the target schema differs, every transformation rule is a business decision about meaning, and every one of those decisions needs an owner who will answer questions about it in six months. Heavy schema change pushes you towards phased, because you want to be wrong about only one slice at a time.
Can you go back, and how long do you have to decide?
Every strategy has a point after which returning to the old system costs more than fixing the new one. For a big bang, that point arrives when the first new transaction lands. For a parallel run, it barely arrives at all, because the old system is still there and still correct. Work out where your point is before you start, since nobody makes that judgement well at two in the morning.
Who signs off that the data is right?
Not who tests it, but who signs. A named person in the business who will say the balances, the customer list, and the open orders are correct. If that name does not exist, your migration has no finish line, and you will discover the problem in the week you hoped to close the project. This is where data privacy and security obligations also land: whoever signs off on the records is usually the person who has to answer for how they are protected in the new system.
Proving that what arrived equals what left
This is the step that separates a data migration from a data loss. Reconciliation is not a phase at the end; it is a rule you write at the beginning, and then run before, during, and after the move.
The rule has to be specific enough that two people would get the same answer from it. "Check the data looks right" is not a rule. "Total open receivables in the target equals total open receivables in the source, to the penny, as at the extract timestamp" is a rule, because it either passes or it fails.
The three levels of reconciliation, and why you need all three
Counts. Rows in, rows out, per table, per batch, and it is the cheapest check that catches the crudest failure, which is a load that stopped halfway and reported success. Never skip it, and never accept a count that is close.
Sums. Add up the numbers that matter — balances, quantities, amounts by currency, totals by period — and compare both sides. Counts tell you records arrived; sums tell you values survived. A field truncated from four decimal places to two passes a count check and fails a sum check, which is exactly why both exist.
Samples. Pull individual records and read them, including the awkward ones. The customer with an apostrophe in the name, the order with a credit note against it, the address with five lines, the record created in a leap year. Counts and sums are blind to a field that landed in the wrong column when both columns hold numbers, and a person reading twenty real records will spot it in minutes.
When the schema changes, reconcile the meaning too
If the target model differs from the source, some checks cannot be a straight comparison, because the two systems no longer count the same way. One system might hold a single order line where the other holds a header and a child record. Write the expected relationship down before the move — one source line becomes one header plus one line — and then test that relationship rather than the raw totals.
This is also where you decide what happens to the records that do not fit. Every migration has them: the incomplete address, the supplier with no tax code, the order referencing a product that was deleted years ago. Decide the rule in advance for each category: fix it, migrate it as is, park it in an exceptions table, or leave it behind on purpose. What you must not do is let the load decide silently, because a pipeline that drops what it cannot parse will do so without telling anybody.
The rollback plan, and the point of no return
A rollback plan is not a paragraph saying you will restore from backup. It is four specific things, agreed before the cutover starts.
The trigger. What condition means you stop? Write it as a threshold rather than a feeling. Reconciliation fails on any financial total, the load is still running at 04:00, or three or more sample records are wrong. If the trigger is "if it seems bad," nobody will pull it, because at four in the morning everything seems recoverable and the team has already been awake for eighteen hours.
The decision-maker. One name, plus one deputy, and both of them awake and reachable during the window. Not a committee. The whole point of naming somebody in advance is that the call gets made in minutes.
The mechanism. Exactly how the old system comes back, tested at least once on something other than production. Rehearse the restore, not just the backup, because a backup you have never restored is a file, not a plan.
The point of no return. The moment after which you finish on the new system whatever happens, because going back now costs more than fixing forward. Put a clock time on it and put it in the runbook. For a big bang this is usually the moment real transactions start landing in the new system. For a phased move it arrives once per slice, and for a trickle it arrives when you stop the sync and start writing only to the target.
After the point of no return, the plan changes from rollback to repair: a prioritised defect list, a named owner per item, and a clear statement to the business about which processes are degraded and for how long. That statement matters more than people expect. A finance team that knows a report is wrong until Thursday can work around it, while a finance team that discovers it themselves stops trusting the whole system.
Testing before you move anything
Most of a data migration plan is testing, and the order of the tests matters as much as their content.
Start with profiling the source, because you will find things nobody warned you about. Count the distinct values in every field you intend to map, and look at what actually lives in the free-text columns, which in most systems is where the business stored whatever the software refused to hold. Find the duplicates, the nulls in required fields, the dates in the wrong century, and the codes that stopped being used in 2019 but never got removed.
Then map, field by field, with the owner's name against each rule, and load into a test target and reconcile it exactly as you would on the night. Then have the business use that target for a day on their own real work, because a tester following a script and a clerk doing their job find completely different problems.
The dress rehearsal
Run the whole cutover end to end, on production-sized data, with the real runbook and the real people, and time every step. This is the single most valuable thing you can do, and it is the first thing cut when a project is behind schedule.
The rehearsal answers questions no document can. Does the load finish inside the window, or inside it only on an idle Sunday? Does the runbook's step 14 actually work, or does it assume a permission nobody has? Who is waiting on whom at 03:00? Does the reconciliation query take four minutes or forty? Time each step and write the times down, because the rehearsal duration is the only honest input to your go or no-go decision.
Rehearse the restore too, because a team that has practised going back is dramatically more willing to make that call when it is the right one, and the willingness is the point. The infrastructure side deserves the same rehearsal, which is where sound IT infrastructure management practices earn their keep: capacity, backups, and access all get tested under something close to real load before the night that counts.
Four ways a data migration goes wrong, and the symptom you would notice
The date was set before the dataset was profiled. Somebody promised a go-live in a steering meeting, and the profiling happened afterwards. The symptom is a scope conversation that keeps ending with "we will clean that up later," and later never has a date against it.
Nobody owned the master data. IT mapped the fields because the business would not decide which supplier record was correct. The symptom appears after go-live, in reports that nobody trusts because the same customer shows up three times with three different balances.
Reconciliation was a checkbox, not a query. Somebody signed a sheet saying the data was verified, but no written rule produced a pass or a fail. The symptom is an argument two months later that nobody can settle, because there is no record of what the correct number was on the day.
The old system was switched off too early. The hardware was reclaimed, or the licence lapsed, and then a question arrived that only the old system could answer. The symptom is somebody hunting for a backup nobody has restored in a year. Keep the source readable for at least one full reporting cycle after cutover, and longer where retention rules apply.
These four have nothing to do with tooling: a data migration rarely fails at the load step, and in our experience it fails at a decision that was never made.
Planning your own data migration
If you are choosing between data migration strategies right now, the sequence below is the one we follow, and the order is deliberate.
Profile the source first, and time a full load on a copy, then answer the five questions with the business in the room rather than on email. Pick the strategy that your two tightest constraints allow, because a strategy chosen against a preference rather than a constraint will fail on the constraint you ignored. Write the reconciliation rules and the rollback trigger, then rehearse the whole thing end to end. Only after the rehearsal do you agree a date in public.
Where the data is going is part of the same decision. If you are moving between platforms rather than only between systems, the cloud versus on-premises comparison is the trade-off to settle before the migration design, not during it, and the broader role of cloud computing in digital transformation sets the target you are migrating towards. Where the move is part of a system replacement, our notes on ERP implementation best practices cover the programme around the data. And once the records are in the new system, the question turns from moving them to running them well, which is where AI and machine learning in data management becomes useful — on clean data with a named owner, never before.
Work with 4Labs Technologies on the move
Our data analytics services team plans and runs migrations of this kind, from source profiling and mapping through reconciliation, rehearsal, and cutover support on the night. Where the move also changes the platform underneath, our IT infrastructure services team handles capacity, backup, and the restore rehearsal alongside it.
If you have a migration coming up, bring us the three things that decide it: roughly how much data there is, how long the business can stop, and whether the schema is changing. That is enough for a useful first conversation about which of the four strategies fits and what the plan would need to contain.
Frequently asked questions about data migration
What are the four data migration strategies?
Big bang, phased, parallel run, and trickle. Big bang moves everything in one window with the business stopped, and phased moves one slice at a time, with each slice live before the next begins. A parallel run processes the same work in both systems and compares the outputs, while trickle synchronises continuously as both systems stay live. Everything else on the market is a variation or a blend of these four.
Which data migration strategy has the least downtime?
Trickle, followed by phased, since both keep the old system available while the new one fills, so the visible outage shrinks to the final switch. That reduction is paid for with engineering: a synchronisation pipeline or a set of temporary interfaces, plus a conflict rule for records that change on both sides. Less downtime does not mean less risk, only risk spread differently.
How do you know a data migration worked?
By a written rule that produces a pass or a fail: counts per table, sums of the values that matter, and a read of individual records including the awkward ones. Write those checks before the move, run them against the test load, and run the identical checks on the night. A named person in the business then signs off on the result.
How long should you keep the old system running?
At least one full reporting cycle after cutover, and longer where retention rules apply. Questions arrive after the first month-end that only the source can answer, and keeping it readable for a while is far cheaper than restoring it under pressure. Readable is enough, and nobody needs to keep writing to it.
What is the point of no return in a migration?
The moment after which fixing forward costs less than going back. For a big bang it is usually when real transactions first land in the new system. For a phased move it arrives once per slice, and for a trickle it arrives when the sync stops and writes go only to the target. Put a clock time on it in the runbook, and agree who calls it.
Do you have to clean the data before migrating it?
You have to decide about it, which is not the same as cleaning all of it. For each category of problem record, choose one of four outcomes in advance: fix it, migrate it as it stands, park it in an exceptions table, or leave it behind deliberately. Migrating known-bad records with a decision recorded against them is defensible, and letting the load drop them silently is not.
