Data migration, minus the meltdown

Let’s face it, when it comes to Oracle projects, data migration can often be left out of the highlight reel. You won’t find it headlining keynote speeches or being showcased with flashy graphics in slick demo videos. Yet, when a new system goes live, it’s the silent backbone that is vital for everything to run smoothly.

In simple terms, data migration is the process of moving data from one system to another, for example, for example, transferring all the AP invoices from an on-premise legacy ERP system into Oracle Fusion; but let’s not oversimplify this, this isn’t just a drag-and-drop exercise.

Challenges appear such as:

• Different data structures – how is this organised and sorted
• Inconsistent formats for example - 01/01/2025 or 1/1/25
• Missing or duplicated records – causing more issues to resolve
• Changing business rules – changing approval rules and whether they work or not
• Compliance concerns – whether HR or Finance
• The classic: "Why is this field empty for half our records?"

It’s not just “moving data.” It’s transforming, validating, and translating business truth from an old world into a new one, and making sure nothing gets lost in translation.

Here are few things to think about:

• What’s your current process? Before diving into change, map out how things are working now. What’s smooth? What’s clunky? Be honest about what needs a refresh.
• What do you actually want to improve? It’s not just about ticking business boxes. Think about how the new system can elevate the user experience, for your team, your managers, and even new joiners.
• Do you have the insights you need? A better system should give you smarter, faster access to data. What reporting or dashboards are you missing today?
• What are others doing? It’s important to look around. What are the best practices in your industry? What tools and workflows are your competitors or peers adopting?
• Are you keeping up with the times? From family-friendly policies to modern budgeting approaches, industry standards are evolving fast. Is your system helping you stay ahead or holding you back?

It’s time to take a long, hard look at your current data. Ask yourself:

• How long do we really need to keep this?
• Is it still relevant, legally, operationally, and financially?
• Are we aligned with Employment law, (General Data Protection Regulation) GDPR, pension regulations, (Financial Conduct Authority) FSA, Tax compliance etc.

Start with historical data, because that's often where clutter builds up. Aim to limit your scope. For example, if an employee’s been with you for 10 years, do you need all 10 years of data? Or would 3 years suffice?

But here’s the catch:

• What if they leave and their new employer asks for a reference covering the past 5 years, and you’ve only retained 3 years’ worth of data?
• Where’s the rest of that data stored?
• Is it still accessible?
• Is it protected?
• And who controls access? Data Migration - Fusion Practices - CTA

That’s just for a job change. Now let’s zoom out, think about the entire employee lifecycle, and that’s just from an HR lens. Layer in Finance - procurement records, expense claims, invoices etc…

See how quickly this turned complex?

This is why data retention can’t be an afterthought. When thinking about data migration or transformation, it’s not just about retention. It’s about purpose and format.

Again, ask yourself:

• How will we be using this data in the future?
• What systems will it sit in?
• Will the old data still fit?

Take something simple like an address. In your legacy system, it may have been entered as a single line. Now, in your new system, there might be four separate fields: street, city, county, and postcode. Will your historical data transfer properly? Or will you suddenly find messy formatting, missing details, or failed uploads?

These small format mismatches can snowball, leading to delays, bad reporting, or worse, compliance issues.

This is why data clean-up, and mapping should be a priority as part of planning. It’s not just about moving data, it’s about making sure it’s usable, relevant, and compatible.

That’s why cleansing your data is critical before any migration. You might have an employee’s employment history neatly stored in your system, but their annual leave? That’s sitting in a spreadsheet, on someone’s desktop. Named “LeaveTracker_FINAL_v3_updated_March.xlsx” (we’ve all seen it).

So, how will that data be transferred? Will it map cleanly into your new system? More importantly will it be trustworthy, consistent, and complete? Your new system should be one unified place, not a folder of spreadsheets, systems, and shared drives.

This is where the real work begins:

• Audit where your data lives
• Check how accurate it is
• Map it to your future system’s structure

Now’s a great time to loop in your (Data Protection Office) DPO, they know the ropes. They’ll help you find that sweet spot between staying compliant, managing risk, and keeping things practical. Think of it like a digital spring clean: clear out the junk, keep what matters, and make sure you're playing by the rules.

When data migration flops, it’s the end users who feel it hard. Suddenly your job history, pay info, or performance reviews are missing or just wrong. Stressful? Totally, especially when your payslip’s on the line.

You expect a smooth system, but instead you get outdated details, blank fields, and clunky screens. Approvals stall, onboarding freezes, reports don’t run, and guess who’s left chasing it all down? You.

Then come the duplicates, errors, and “why am I listed twice?” moments. Everyday tasks like booking time off or checking your payslip turn into support tickets and long waits.

If your FTE or working hours are wrong? That’s not just annoying, it can mess with your pension, compliance status. Bottom line? If the data’s a mess, the system’s a failure. Trust breaks fast and suddenly no one’s winning.

Data isn’t just something you move. It’s the foundation of your business processes, decisions, success and when your system goes live, you want confidence, not chaos.