Inside every migration plan there’s a document called the cutover runbook. It’s typically 40 to 120 pages, lists the order in which systems get switched over during a single weekend, the rollback steps for each, the communication plan, and the champagne. In our experience, the migrations that go well are the ones where the cutover runbook gets quietly deleted from SharePoint a month before the supposed weekend, because the migration has already happened module by module and there is nothing left to cut over.
The best migrations are boring. They roll out gradually, module by module, over weeks. Users don’t get a memo. They get a link to a new URL that does the same thing, only faster and in a browser.
Why gradual beats big-bang
Big-bang cutovers compress every risk into a single moment. A missed validation rule, an unexpected data format, a load issue under real traffic — any one of them affects the entire organization at once. Rollback means going back to Oracle Forms, which means admitting the project failed, which means political consequences nobody wants to absorb.
Gradual migration distributes risk across time. Module 1 ships to 20 users. They use it for two weeks. Issues surface and get fixed. Module 2 ships. Repeat. By the time the last module switches over, the process is routine and the team is calibrated.
Back in 2010 I watched a European distributor attempt a classic big-bang cutover one Saturday night. The old Forms system went down at 10 PM, the new Java client came up at 2 AM, and by 9 AM Monday the CEO was on a call demanding we roll everything back because the warehouse pickers couldn’t scan receipts. The actual defect was trivial — a barcode field truncated at 12 characters instead of 14 — but by then the political damage was done and the project lost another nine months to a “stabilization phase” that was really a re-plan. That Monday morning is why I refuse to quote a single-weekend cutover, ever.
Parallel operation is the architectural requirement
This pattern only works if both systems can run simultaneously. The Oracle Forms application and the new web application have to coexist against the same database for as long as the migration takes.
It sounds complicated. It isn’t, when the architecture supports it. The new system reads and writes through a REST API layer. The old system reads and writes through native Oracle access. Both hit the same tables. Both see the same data. A user can enter an invoice in Forms and see it immediately in the new web UI, or vice versa. The database stays the source of truth. The interface is just a window onto it.
What the user experience actually looks like
The ideal rollout for an end user runs like this:
- An email arrives: “Your new Contractors module is ready at app.company.com/contractors.”
- They open it. It looks modern but familiar. The same data is there. The same buttons do the same things.
- They enter a few records. Validation behaves the same way. Search is faster. Columns sort. It works on a tablet.
- A week later, they’ve forgotten about Oracle Forms entirely.
No training sessions. No 50-page user manual. No change management initiative. Just a better tool that behaves the same way the old one did. That’s the migration nobody notices, and in our experience it’s the only kind that actually succeeds at enterprise scale.