Transformation

How to upgrade a database platform without losing the data that matters

A database platform upgrade is not a find-and-replace. It is a controlled migration of the thing the business actually trusts: the data.

By Zakir Hoosen, Director, Fuzzelogic Solutions. Plain English guidance for business leaders.

A database platform upgrade means moving data from one database engine or version to another while the business keeps running. It is not a weekend cutover. It is a designed change: what moves, what stays, how you prove the new platform is right, and how you go back if it is not.

Most organisations know the database is old. The vendor has stopped supporting it. The performance is degrading. The security patches are running out. The upgrade opportunity is real. So is the cost of getting it wrong.

That finding is about AI, but the problem is older than AI. If the data sitting on the current platform is incomplete, inconsistent, or poorly documented, moving it to a newer engine does not fix the underlying issue. The upgrade has to address the data quality, not just the database version.

Fuzzelogic Solutions has been modernising banking, insurance, healthcare, retail, manufacturing, and government platforms since 2007. Nine regulated financial institutions sit among our clients. Platforms run on three continents. This article is the design you can review before anyone starts migrating tables.

Why the database upgrade is harder than the vendor says

The vendor will tell you the upgrade is straightforward. They will give you a migration tool, a compatibility guide, and a weekend window. That is the version of the upgrade that works in a demo. It is not the version that works in production.

The hard parts are not technical. They are organisational. The business does not know what data it has. The data does not match the documentation. The integrations depend on behaviour that changed between versions. The reporting relies on quirks that nobody recorded.

1. Data volume. What you think you have and what you actually have are usually different. Trial-load and count before you commit.
2. Schema drift. The documented schema and the live schema are different. Columns were added, renamed, or repurposed without updating the docs.
3. Integration contracts. Applications depend on specific database behaviour: date formats, error codes, connection pooling, transaction isolation. Change the behaviour and the applications break.
4. Reporting dependencies. Reports that work on the old platform may fail silently on the new one. Silent failure is worse than an error message.
5. Rollback complexity. Going back is not always as simple as restoring a backup. If the old and new platforms have different formats, rollback becomes a migration in reverse.

Do not start the upgrade until you can answer all five. If the answer to any of them is "we will find out during the migration", you are not ready.

The honest version of a database platform upgrade is slower than the vendor promises. It is also the only version that works. The vendor wants to sell you a licence. You want to keep the business running. Those are different objectives. The assessment exists to surface the gap between them.

The design you should be able to review

A serious database upgrade has a written design. Not a slide with arrows. A design an architect can challenge. Three patterns cover most high-stakes work.

Lift and shift with validation

Move the data as-is to the new platform. Run the same applications against it. Compare outputs. This is the simplest pattern and the most dangerous if you skip the validation. The data moves, but the behaviour underneath changes. You need to prove that every query, every report, and every integration still works correctly.

Schema migration with parallel run

Transform the data as part of the move. Fix the schema drift. Clean the data. Load it into the new platform. Run both platforms in parallel for a defined period, with named owners comparing outputs. Parallel run is slow and expensive. It is also the honest way to prove the new platform produces the same results as the old one.

Phased cutover by application

Move one application at a time to the new platform. The old platform remains the system of record for everything else. You cut over one slice, prove it works, and move to the next. This is the strangler fig pattern applied to databases.

Whatever pattern you pick, three designs have to sit underneath it.

Data movement. Map every field that matters. Say what you will clean, what you will leave, and what you will not move. Trial-load into a non-production environment. Reconcile counts, totals, and samples. Repeat until the reconciling items are understood, not ignored.

Testing gates. Do not test at the end. Gate the programme: environment ready, trial load accepted, integration proven, operational runbook rehearsed, rollback rehearsed. A gate that can be waived by optimism is not a gate.

Rollback. Write down how you go back. Restore the old platform. Re-point connections. Re-open access. Name the person who can call it, the evidence they need, and the time they have. If rollback is "we will think about it on the night", you do not have a design.

Database upgrades fail for the same reasons as other transformations: the data work was underestimated, the integrations were not listed, and the process change was treated as someone else's problem. Count those lines in the first estimate.

A roadmap with decision points

Start with a verdict you own. Not a vendor demo. Not a migration tool download.

1. Assess (two to four weeks, fixed price). What the current database actually does. Which data is trustworthy. Which integrations are load-bearing. Which upgrade is justified. You own the verdict and the roadmap whether or not we build any of it.

2. Trial-load. Move a representative slice of data into a non-production environment on the new platform. Count records. Run key queries. Compare outputs. This is where the schema drift shows up.

3. Design the pattern. Lift and shift, schema migration, or phased cutover. Draw the data flow, the compare process, and the rollback. Review it with architecture, operations, security, and the business owner.

4. Build the migration. Fuzzelogic delivers a working version in twelve to sixteen weeks from an agreed roadmap, against twelve to eighteen months in house. That is a working slice, not a full platform replacement.

5. Prove it. Trial-load the full dataset. Parallel compare where the risk requires it. Operational rehearsal. Security review. Gate review with the right to stop.

6. Cut over. Planned window. Named decision maker. Rollback live until the slice is accepted.

Decision points that must be real, not ceremonial:

1. Go / no-go after assessment. If the honest answer is that the database should not be upgraded yet, put that in writing.
2. Go / no-go after trial load. If the data cannot be reconciled, stop.
3. Go / no-go after parallel compare. If the outputs do not match within tolerance, stop.
4. Go / no-go on cutover night. If rollback conditions are met, roll back. Reputation survives a delay. It does not always survive a bad cutover.

How to talk about value without inventing numbers

Do not put a made-up percentage in the board paper. Use a framework the finance director can audit.

Hard cost. Licence, infrastructure, and the people who only exist to keep the current platform alive. Use your actual run-rate, not a vendor's "typical saving".

Risk reduction. Failed audits, security exceptions, performance degradation, and the cost of a failed upgrade. You will not get a precise number. You can still say whether the current risk is acceptable.

Operational efficiency. Query performance, report generation time, backup and recovery speed. Measure the current baseline before you claim an improvement.

Compliance. Faster evidence, clearer lineage, fewer manual controls. If the regulator or auditor cannot see the trail, the new platform has not improved compliance.

Time to value. A working slice in twelve to sixteen weeks is a time-to-value number we will stand behind for scoped work. A full platform upgrade is a programme of slices. Budget it that way.

Long-term cost of ownership. Three-year cost of keeping the current platform versus three-year cost of the new one, including maintenance. If the new platform has no owner after launch, the cheaper build is the more expensive outcome.

Database upgrades overshoot for the same reasons: the data work was underestimated, the integrations were not listed, and the process change was treated as someone else's problem. Count those lines in the first estimate.

What changes by industry

The pattern language is shared. The constraints are not. We have upgraded banking, insurance, healthcare, retail, manufacturing, and government platforms. Other sectors below are included because the constraints are real, not because we are claiming a case study in each one.

Banking and insurance. Customer records, payments, and ledgers cannot be "best effort". Data residency, audit trails, and accounting standards are design inputs, not a later compliance check. The upgrade has to account for regulatory reporting dependencies. If a report breaks silently, you have a compliance issue, not just an IT issue.

Oil and gas, mining, minerals, quarry. Operational continuity in remote sites matters more than a tidy architecture diagram. Plant and control systems are not office software. The upgrade has to respect maintenance windows the operation will actually honour. Remote sites may have limited connectivity for vendor support during the cutover.

Manufacturing, automotive, shipyards, construction. Production-line continuity is the constraint. Quality systems must keep certifying product during the change. Supply-chain data is messy. Technical debt here is not an IT aesthetic. It is the reason a new product introduction takes a quarter longer than the competitor.

Military and defence. Accreditation, configuration management, and long support lives dominate. Some environments are air-gapped. The upgrade must be tested in environments that mirror operational conditions. Rollback must not depend on a vendor's cloud console.

Agriculture. Seasonal windows are real. You do not upgrade a harvest system in harvest. Design around the calendar, not the vendor's sprint board.

Logistics and packaging. Volume, scan events, and customer cut-off times leave little room for an unplanned stop. If the warehouse database is wrong for an hour, the trucks still arrive.

If your sector is not on that list, the questions are the same. What cannot stop. What must be true on the morning after cutover. Who can halt the programme.

Common pitfalls, and the design that avoids them

Skipping the trial load. Live data is not the sample the vendor used in the demo. Trial-load until reconciliation is boring.

Moving the mess. If you copy bad data into a new platform, you have a more expensive mess. Cleanse what you will use. Leave what you will not. Say which is which.

No rollback. Hope is not a plan. Rehearse the return path.

Ignoring integration contracts. Applications depend on specific database behaviour. Test every query, every report, and every integration against the new platform before you cut over.

Big-bang cutover. It concentrates all risk into one night. Prefer a slice you can reverse.

No owner after launch. Upgrade without maintenance is how the next legacy problem is born. We maintain what we build.

If the honest answer is that a database should not be upgraded yet, we put that in writing rather than rebuild it anyway.

Start with the design, not the cutover date

The transformation opportunity is to stop paying for a platform that cannot keep up, and to own one that can. The cost of staying is real. The cost of a bad upgrade is also real. The difference is a design you can review, a slice you can reverse, and a partner who will tell you when not to proceed.

Start with the assessment. Two to four weeks, fixed price, and you own the verdict and the roadmap whether or not we build any of it. When you are ready to talk software, maintenance, or AI, call Fuzzelogic Solutions and ask for Zak.

www.FuzzelogicSolutions.com | info@FuzzelogicSolutions.com | +44 (0)1624 618950

Zakir Hoosen, Director Suite 1B, 11 Circular Road, Douglas, Isle of Man IM1 1AF +44 (0)7624 482071 | +44 (0)1624 618950