Ask why a business-critical Oracle Forms system has not been migrated, and the honest answer is rarely inertia. It is fear of the switch. A system the business cannot afford to have down for a day feels far too risky to replace in one move, so the safest-seeming choice is to leave it alone. The instinct is understandable. It is also based on a model of migration that nobody should be using for a critical system.
That model is the big-bang cut-over: build the entire replacement, then switch from old to new in a single moment. For a critical system it is the worst possible shape of risk. There is no graceful way back if something is wrong. Every problem the project contains surfaces at once, on go-live day, under maximum pressure. And all the risk of years of work is concentrated into one switch. The fear of migrating a critical system is, really, a perfectly rational fear of the big-bang approach.
There is a different approach in which the frightening moment does not exist. In a phased migration with parallel running, the old and new systems operate side by side on the same database, and users move across one module at a time. Each module is proven in production before the next is attempted. There is no single day on which everything changes — only a series of small, contained steps, each verified before the next begins. The migration becomes a sequence of manageable moves rather than one irreversible leap.
| Dimension | Big-bang cut-over | Phased / parallel running |
|---|---|---|
| Go-live | Single switch, all at once | Module by module, over time |
| Rollback | All or nothing | Per module, back to Forms |
| When problems surface | All on go-live day | Early, one module at a time |
| Risk concentration | Maximum, single moment | Spread and contained |
| Business disruption | High | Minimal |
| Confidence | Hoped for until launch | Earned at each step |
The detail that makes this work is the shared database. Because the old Forms modules and the new modules read and write the same data, there is no risky synchronisation between two systems and no period where the organisation has two competing sources of truth. A module migrated today operates on exactly the same data as the Forms module running beside it. That single architectural choice removes the data-integrity problem that makes most side-by-side migrations dangerous, and it is what allows users to be moved gradually without anything being duplicated or reconciled.
In practice this means each migrated module is genuinely live, not a parallel copy waiting for a future switch. The users of that module work in the new system on real data, while everyone else continues in Forms on the same data, and the two coexist for as long as the migration takes. There is no shadow period of double entry and no reconciliation step, because there is only ever one set of data underneath both. That is what makes “no downtime” literal rather than aspirational: at no point is the system unavailable, because it is never switched off and on — it is migrated out from under the users a piece at a time.
Parallel running also keeps a way back open at every step. If a migrated module turns out not to be right, you fall back to the Forms version of that module without unwinding the rest of the project. The risk taken at each step is small and reversible, which is the opposite of a big-bang cut-over. This is how genuinely critical systems are moved without downtime — the Santander Leasing migration is one example of a business-critical system moved this way, module by module, without being taken offline.
Phasing also lets you choose where to begin, and the wise choice is often the hardest module first, run as a proof of concept. If the most difficult part of the system migrates cleanly, the rest is lower risk by comparison, and you have learned that early and cheaply. The same sequencing freedom lets you prioritise the modules that carry the most business value or the most compliance exposure, so the migration delivers where it matters first rather than last.
Phasing also changes the conversation with the rest of the business. Instead of asking stakeholders to wait months for a single, nerve-wracking launch, you can show working modules in production along the way, each one a small, visible proof that the approach is sound. Confidence is built incrementally rather than staked on one day, and the inevitable question — “is this actually going to work?” — is answered by results in front of people rather than by promises. For a critical system, that steady accumulation of evidence is worth as much as the technical risk reduction.
Next step. The diagnosis produces the dependency map that makes safe phasing possible, showing which modules can move independently and in what order.
