The old platform is still running, the new one is half built, and reporting is frozen

Six reasons a platform conversation starts, and none of them is a technology preference

Nobody wakes up wanting a new data platform. Something else has gone wrong first, and it is rarely the technology itself.

1. 01The platform was right for the company that chose it

   It was chosen for the business you were then. The volumes, the number of source systems and the people depending on the output have all changed since. The platform has not, and neither has the decision that picked it.

2. 02The licence renewal has arrived and nobody can justify it

   Procurement wants a business case by a date. The only people who could write one are the people keeping the platform working next Tuesday, and they have no way of saying which workloads are driving the invoice.

3. 03The old system was never switched off

   The migration finished, or was declared finished. Both bills still arrive and nobody can say with confidence which reports still read from the old one, which is exactly why nobody will turn it off.

4. 04Every quote begins with a freeze on new reporting

   The business is asked to stop asking questions until the migration lands. It will not. A shadow reporting layer grows in spreadsheets during the freeze, and that layer is still there long after the cutover.

5. 05A previous attempt stalled halfway

   Half the workloads moved, half did not, and the sponsor who knew the plan has moved on. You now carry the operational burden of two platforms and the benefit of neither.

6. 06The bill grows with the data, not with what the data is worth

   Ingesting more raises the invoice whether or not anyone reads the result. A dataset nobody has opened costs the same to hold as the one the board reads before every meeting.

Most of these are commercial or operational rather than technical, which is why what they add up to is a platform decision rather than a reporting one.

From the sentence you said on the call to the decision it actually is

Each complaint belongs to a different decision, and the order they get answered in matters more than any single answer.

Left, the sentence somebody says. Right, the decision it belongs to. They arrive tangled together, and a contract renewal date is what forces the order they get answered in.

Why the bill grows with the data rather than with the value

The business case is built on cost, so it is worth being precise about where the money actually goes.

Four answers come out of the audit week, and only two of them involve a migration. The first one is a real answer here, not a polite one.

1. Answer 1The platform still fits and the pain is somewhere elseDo nothing

   A slow dashboard and a late month end can both be modelling or query problems. A new platform carries those across intact, at considerable expense. If that is what the audit week finds, we say so, and you have spent a week rather than a year.

2. Answer 2The problem is the contract, not the technologyRenegotiate

   Sometimes the platform is fine and the commercial terms are not. Knowing exactly which workloads drive the bill, and which of them could credibly run elsewhere, is what gives you something to say in the renewal conversation.

3. Answer 3One or two workloads leave and the rest staysMove part

   Sometimes only the heaviest workloads justify moving at all. The rest can stay where it is for years without anyone being worse off. Partial is a legitimate end state, not a migration that failed to finish.

4. Answer 4The platform has to change, and here is the orderMove it

   When the answer is a full move, the plan names the first workload, the reconciliation that will prove it, and the date the old platform is switched off. All three are written in week one, or it is not a plan.

Three ways a modernisation gets attempted

Only the third one has a date on which the old bill stops.

1. Approach 1Big bang, with a freeze in front of it

   Everything moves on one weekend, and new reporting is frozen for the months before it. The business does not actually stop asking questions during a freeze, so a shadow layer of spreadsheets grows and then survives the cutover. The platform has been modernised and the reporting has moved into Excel.

2. Approach 2Halfway, then stalled

   The straightforward workloads move, the awkward ones do not, and then the sponsor changes. Both platforms stay on, both bills arrive, and the team supports two of everything. Nothing was decommissioned, so nothing was saved.

3. What we doParallel, reconciled, with a decommissioning date

   One workload at a time runs on both platforms, the outputs are compared, and the old path is switched off once the comparison has stopped being interesting. The freeze is measured in the hours around a single cutover rather than the months around a programme.

Six parts. The first one can end the engagement, and the last one is the part that gets left until there is no budget left for it.

1. DecisionWhether to modernise, argued from your own workloads01

   We profile what actually runs, what it costs and who reads the output, then say whether a move is justified. The evidence is your query history and your invoice, not a comparison table between two vendors.

2. FormatOpen table formats, so the next decision stays yours02

   Data lands in an open table format rather than a proprietary one, so the storage layer can be read by more than one engine. The point is not fashion. It is that leaving again later costs a configuration change rather than another migration.

3. DeploymentYour cloud account, not a vendor's03

   Compute and storage run inside the customer's own cloud subscription wherever the workload allows it. Your security team already governs that account, the cost arrives on a bill your finance team can already decompose, and the data does not quietly become somebody else's asset.

4. Parallel runOld and new running side by side, reconciled04

   The new platform processes the same inputs as the old one for an agreed period and the outputs are compared row by row rather than sampled. Nobody is asked to trust the new numbers before the comparison has become boring.

5. DecommissionSwitching the old platform off, on a date05

   Named date, named owner, written down in week one. The old platform goes read-only, then archived, then off. Until it is off, the saving is a forecast rather than a saving.

6. CostA bill that tracks value rather than volume06

   Usage and cost put side by side per dataset, and workloads priced by what they actually need rather than all held at the same service level. The aim is that holding more data does not automatically cost more money, and that switching something off is an ordinary decision.

How the parallel run actually works

Five stages per workload, repeated. Nothing is switched off until the stage before it has been uneventful for a while.

1. 01Both platforms read the same sources

   The new platform ingests from the original source systems, not from the old platform's output. Chaining the new one behind the old inherits every quirk you are trying to leave and hides them until the day you disconnect.

2. 02Outputs are compared, not sampled

   Counts, keys and money by period, old against new, on a schedule. Differences are listed individually. A percentage match is not a reconciliation, it is a way of not looking at the rows that disagree.

3. 03Reads move first

   Reporting and downstream consumers are pointed at the new platform while the old one keeps running untouched. If something is wrong, pointing them back is a configuration change rather than an incident.

4. 04Writes move, and the old path goes read-only

   The old platform stops receiving new data and stays readable. This is the freeze, and it is per workload rather than across the whole programme, which is the entire reason it can be measured in hours.

5. 05The old path is removed, not left dormant

   Dormant pipelines get switched back on by somebody solving a problem at seven in the morning, and then two platforms are live again. The path is deleted and the schedule is removed with it.

Repeated per workload rather than run once across the estate. Only one workload is ever mid-cutover, which is what keeps the freeze short and the rollback cheap.

What the reconciliation has to prove before a workload switches

A workload has not moved when the data lands on the new platform. It has moved when the person answerable for a number is willing to quote the new one.

1. 01The comparison runs on every load, not once before the switch

   A reconciliation run once, the week before a switch, proves the state of the data that week and nothing else. Running it on every load is what turns the comparison into something nobody is nervous about.

2. 02Financial figures tie to the finance system, not to a shared extract

   If both platforms read the same intermediate file, they will agree with each other and can both be wrong. The check has to run against the system the finance team treats as the record.

3. 03Late and restated data behaves the same on both

   The awkward case is never the happy path. It is the record that arrives three days late and changes a period that was already closed. If the two platforms handle that differently, the reconciliation drifts quietly and you find out at quarter end.

4. 04Rounding, time zones and currency are pinned before the comparison starts

   Variance from those three looks like a data problem and is not. Settling them first keeps the argument on the records that genuinely disagree rather than on the fourth decimal place.

5. 05Remaining differences are explained and signed, not tuned away

   Some differences are correct, because the old platform was wrong. Those get written down and agreed by name, rather than adjusted until the two numbers match and nobody knows why.

6. 06Rollback is a configuration change

   Until the old path is removed, going back has to be a switch somebody can throw without a deployment. If rollback needs a release, nobody will agree to switch in the first place.

We write this list against your own workloads during the Week 1 audit, and you keep the one-pager whether or not the rest of the work goes ahead.

Decommissioning, the step that gets planned last and then dropped

Until the old platform is off, you have added a platform rather than replaced one. This is the part we insist on writing down in week one, because it is the hardest thing to fund once the new platform is already working and the programme is out of money.

1. 01Name the date and the owner in week one

   Before any data moves, the plan says when the old platform goes off and who signs that it has. A decommissioning step with no name against it is a wish, and it is the first thing to fall out of the plan when the timeline tightens.

2. 02Inventory what still reads from it

   Scheduled jobs, embedded connections, an integration somebody built for a customer, and a spreadsheet on a desktop refreshing over an old connection. The last category is the one that stops a shutdown, and it is only found by watching what actually connects rather than by asking.

3. 03Make it read-only and see who complains

   A planned read-only period surfaces the consumers no inventory found. A complaint during that window is useful information. The same complaint after a deletion is an incident.

4. 04Archive what has to be kept, then prove you can read it

   Retention obligations do not lapse with the licence. Archive into a format you can still open without the vendor, and restore something from the archive before the contract ends rather than after.

5. 05Switch it off, then cancel the contract

   The technical shutdown and the commercial cancellation are two tasks with two different owners, and the second is the one that gets forgotten. A platform that is off but still invoicing has saved you nothing.

What the first six weeks look like on a platform move

The same three phases as every engagement, and the interesting question is what has to be true by week three.

1. Week 1The audit, fixed fee

   Two calls, your query history and your invoice, and one workload followed from the source system to the number somebody uses. You get a one-pager naming whether to move at all, what moves first, and when the old platform goes off. Yours whether or not we go further.

2. Week 2The first workload is chosen

   A pod of three starts on the workload that carries real decisions and has the fewest dependencies, not the one that demonstrates best. The demonstration workload teaches you nothing about whether the reconciliation will hold.

3. Week 3Both platforms are running it

   The first workload runs on the new platform beside the old one, with the comparison visible to your team. This is the week the awkward records surface, which is exactly why it is not week nine.

4. Weeks 4 to 6Reads move, then writes

   Consumers are pointed at the new platform, the old path goes read-only, and the workload is done. Across our engagements the median time to a first production-grade artefact is six weeks.

5. Week 7 onwardsThe rest of the estate, and the shutdown

   Quarterly reviews and on-call governance, the remaining workloads in the same pattern, and the decommissioning plan executed against the date agreed in week one.

Where week three falls in a six-week move

The point of week three is not speed. It is that the awkward records surface while changing the plan is still cheap.

Six weeks drawn as 42 days. Six weeks is our median time to a first production-grade artefact, measured across all of our engagements. On a platform move, week three is the first parallel run rather than the cutover.

We have not published a named platform modernisation case yet, so these are firm-wide delivery figures, and we will say on the call which of them came from work like yours.

What buyers ask before anything is signed.

• Your warehouse bill doubled and nobody changed the data volumeWarehouse spend almost never grows because of storage. It grows because a schedule, a cache or a refresh strategy changed quietly, and nobody connected the two.
• Starting a warehouse migration by translating stored procedures will stall itTranslating a procedure estate in list order is how a migration loses a year. Start from the reports people genuinely read and work backwards.
• A supplier changed a column and your pipeline found out in productionData contracts assume a producer you can hold to account. When the producer is a vendor or a partner, you need something else entirely.