Staged government legacy system migration, with the record intact

Where this leaves a public-sector team stuck

You are running a platform that still works but can no longer be safely changed. The vendor has moved on, the people who built it have retired, and the supplier list for its skills gets shorter every year. The record inside it is legally significant, the service on top of it is one citizens depend on, and the budget to replace it is public money under scrutiny. So the project keeps slipping. Touching the system feels riskier than living with it, and a failed migration becomes a headline rather than a quiet lesson. The data you need for reporting and policy stays trapped, and every year the platform sits there it gets harder and dearer to move.

Why a new platform on its own does not solve it

The temptation is to buy the replacement product and plan a single switch-over weekend. That is the pattern behind most public-sector migration horror stories. A big-bang cut-over bets the whole service, and every record, on one event going perfectly. When it does not, you cannot easily roll back, the citizen-facing service is down, and the archive you were obliged to preserve is in question. A new platform is only the destination. It says nothing about how you get the records across faithfully, how you keep the licence or payment service live during the move, or how you show an auditor that the migrated record is true to the source. Those are process problems, and a tool does not carry process.

How we deliver it for government

We migrate in small batches and prove each one before the next, so risk stays contained and reversible rather than concentrated in a single date. We start by understanding the existing system and its records in depth, including the undocumented behaviour that decades-old government systems accumulate. Then we move a low-risk, well-bounded function first to prove both the approach and the fidelity of the migrated record, while the old system keeps running in parallel. That is principle #7, working in small batches, applied where the cost of a misstep is public.

Around that, two things matter more in government than almost anywhere else. Every decision and process step is recorded and version-controlled, principle #6, so the migration is controlled, reversible, and fully auditable for the officials accountable for it. And because the public sector operates under scrutiny, we help you hold a clear, communicated position on how AI and data are handled through the move, principle #3, so the explanation you give and the system you run are the same thing. You can read how these principles work across our our approach.

When staged migration is the right call, and when it is not

Stage it when the records carry legal weight, when a service cannot go dark, and when an auditor will ask you to prove the migrated record is faithful. That is the realistic state of most registries, case management, grants, licensing and payment platforms. Do not over-engineer a staged parallel run for a small internal tool with no public exposure and no retention obligations, where a straight rebuild is quicker and cheaper. We will tell you which situation you are in before you commit budget, and we will say so plainly if the honest answer is the cheaper one.

Australian context

Government migrations sit under recordkeeping obligations, including those administered by the National Archives of Australia and state archives, alongside privacy and FOI requirements that demand provenance, retention and disposal be preserved. Security is shaped by the Essential Eight and the Information Security Manual, with IRAP assessment relevant where systems handle sensitive or classified information. Procurement and accountability frameworks, such as the Commonwealth Procurement Rules and their state equivalents, expect the spend to be transparent and defensible. We work with agencies, councils and authorities of any size, and we run each migration to those recordkeeping, security and accountability standards. We do not make regulatory promises on your behalf, and YMYL sign-off stays with your accountable reviewer.

Related services and sectors

Legacy migration usually pairs with cloud and integration work, so explore our services for the platform side and see how we apply the same staged, documented approach across our industries. For the technical foundations behind a controlled, reversible migration, see our technologies.