Before you touch a single configuration setting in Oracle Fusion, you have a data problem. Most organizations don’t find out until it’s too late.
Rob Leech, Fusion Finance Lead at Imperial College London, joined us for a session on what real-world ERP migration data preparation actually looks like — not the theory, but the lived experience of an institution with records dating back to 1999, 250,000 supplier records, and over 100,000 open purchase orders still sitting in their system.
Here’s what stood out.
Your legacy system is a time capsule. And not the good kind.
Imperial has been on Oracle since 1999. Every upgrade since then has been exactly that — an upgrade, never a reimplementation. Which means they never had a forcing function to clean house. By the time they committed to Fusion in 2023, they were sitting on:
- 250,000 active supplier records (170,000 unused in the past two years)
- 100,000+ open purchase orders, some going back to day one
- 80,000 customer records that needed deactivating
- £19 million in unapplied receipts
- 1 million active GL account code combinations
None of this is unusual. It’s just rarely talked about.
“The way data’s been treated up until now is: as long as the job gets done, who cares. Get the work out the door — it doesn’t matter what we’re leaving behind.” — Rob Leech
The four pillars — and why they never stop
Rob’s framework for data migration comes down to four activities: cleansing, mapping, enrichment, and transformation. The important thing he stressed is that these aren’t sequential steps. They cycle, constantly, for the duration of the migration. New issues surface after each migration run. Data in the source system keeps changing. Mappings that seemed settled turn out to need revisiting.
“There’s no line in the sand. It always comes at you.” — Rob Leech
Cleansing is removing what you don’t need. For Imperial, that meant deactivating suppliers who hadn’t been paid in two years, closing POs older than five years outright, and giving departments a window to review anything between two and five years old before the cutover.
Mapping is the translation work between EBS and Fusion — field by field, object by object. Even within the Oracle family, the data models differ. A field called “contact number” in EBS becomes “mobile contact number” in Fusion. Multiply that across every object in the system.
Enrichment is improving what you do bring across. Imperial is adding DUNS numbers to supplier records, populating credit risk data for customers from Dun & Bradstreet, and creating a new descriptive flexfield to preserve original supplier creation dates. Without it, every supplier would appear to have been created on go-live day.
Transformation is the changes made in transit, outside either system. Rob’s advice: keep this to a minimum. Do as much as possible in your source system. Transformation in a spreadsheet black box is harder to audit, harder to trace, and harder to fix if something goes wrong.
Cleanse in your source system — not during migration
This was the principle Rob came back to more than once, and it’s worth taking seriously.
When you clean data in your existing system, you improve your current system of record: the one your team is still working in every day. If go-live gets pushed (and it might), that work isn’t wasted. When you clean data in transit, you lose that benefit, and you add complexity to an already complicated process.
“Forget thinking everything’s about functionality. Data is kind of what you have to live and breathe.” — Rob Leech
Imperial ran five migration cycles. Rob said he wished they’d had seven or eight, because every cycle taught them something new about their data.
A simple test for what’s worth migrating
With hundreds of thousands of records, you can’t make case-by-case decisions. Imperial settled on four questions to apply at scale:
- Is it current?
- Is it relevant?
- Is it necessary?
- Is it good quality?
If the answer to any of those is no, don’t bring it across. A clean start in Fusion is worth more than the false comfort of migrating everything.
What nobody tells you about old data
Some of it is beyond saving.
Imperial had roughly 200 AP invoices in a corrupted state that couldn’t be fixed from the front end and couldn’t be resolved through their ICT team. Raising 200 Oracle Service Requests wasn’t practical. Their solution: exclude those invoice IDs from the migration entirely and make accounting adjustments to account for them.
It’s not a perfect answer. But sometimes the choice is between a pragmatic workaround and an open blocker.
“We’re not going to go and close 70,000 purchase orders manually. That’s just not feasible, regardless of how many bodies you could throw at it.” — Rob Leech
That’s where tooling becomes the difference between a project that finishes and one that doesn’t. Guy Kelly, who handled much of the hands-on data work, described the before-and-after of switching from Oracle’s native PO Close functionality to More4apps:
“Having to use the built-in Oracle functionality was incredibly manual — going through manually, unticking each purchase order you wanted to keep. That introduced a lot of potential for human error, it was very time-consuming. And wildly dull. More4apps took a week-long job and condensed it down to however long my aging laptop would take to make those changes.” — Guy Kelly
Don’t underestimate the work. And build in reconciliation time.
Rob’s closing advice was blunt: don’t underestimate the work. Give yourself more migration cycles than you think you need. And, something Imperial learned the hard way, build in dedicated time after loading data into a test environment to reconcile it before testing activity starts. Once transactions start hitting the system, your ability to get a clean baseline view disappears.
Guy’s take was equally direct:
“A few days spent looking at what solutions are available, and the week or so required to get access to tools you might not already have, is worth a month’s worth of some poor fool like me manually going through whatever system you have.” — Guy Kelly
What’s next for Imperial
Imperial goes live in November 2026. They’re already looking ahead to how More4apps fits into their Fusion environment, specifically around FBDI limitations and the need to handle spreadsheet journal uploads with supporting attachments, functionality Oracle’s native desktop integrators don’t fully cover.
The data work doesn’t end at go-live. It just moves to a new system. Watch the whole session below.
Facing a migration of your own?
If Imperial’s story sounds familiar — aged records, supplier data that hasn’t been touched in years, purchase orders no one can account for — you’re not alone. And you don’t have to tackle it manually.
More4apps gives Oracle EBS teams the speed and control to clean, update, and manage data at scale, directly in your source system, before you ever touch a migration file. Whether you’re months out from go-live or just starting to scope the work, we’d love to talk.