Somewhere in your business there’s probably a spreadsheet called “stock_FINAL_v3_ACTUAL.xlsx” that one person understands, three people are scared to touch, and everyone quietly relies on. That’s usually the moment data migration stops being an IT concept and becomes the thing standing between you and a working ERP system.
TL;DR
- Most ERP rollouts don’t fail because of the software. They fail because the data moving into it was never cleaned or mapped properly first.
- Expect cleaning your data to take longer than actually moving it, often the majority of the whole migration effort.
- Test with a small batch before you touch everything, and reconcile totals rather than assuming a match.
- Set a clear cutoff date, and have a way back if something goes wrong.
- Blue Lotus 360’s implementation team handles the heavy lifting on mapping and validation, so this doesn’t land entirely on you.
Panorama Consulting’s research on ERP implementations has consistently found that around one in five projects are considered outright failures, with data quality and migration among the most commonly cited causes. Not because moving data is technically hard. Because it’s tedious, easy to underestimate, and usually the first thing to get rushed when a go-live date starts looking tight.
Step 1: Find out where your data actually lives
Before anything else, work out what you’re dealing with. For most businesses moving off spreadsheets, that means several Excel workbooks with different owners, maybe an old accounting package, a folder of supplier PDFs, and someone’s personal notebook of customer preferences that’s never been typed up anywhere.
List every source. Don’t assume it’s just “the spreadsheet.” It rarely is.
Step 2: Decide what’s actually worth moving
Not everything needs to make the journey. Ten years of invoices for suppliers you haven’t used since 2019 will just clutter the new system. Split your data into what has to migrate (active customers, current stock, open orders, chart of accounts) and what can stay archived in its current format for reference.
This is also the point to sort data into rough categories, since each behaves differently during migration:
- Master data: customers, suppliers, products, employees
- Opening balances: account balances, stock on hand, outstanding receivables and payables
- Transactional data: open purchase orders, invoices, work in progress
- Historical data: past reports and records you want to keep but won’t actively use
Step 3: Clean it before you move it, not after
This is the step people underestimate most, and it’s usually where the bulk of the actual effort goes. Duplicate customer records under slightly different names, phone numbers formatted three different ways, product codes that mean one thing in the spreadsheet and something else on the invoice. All of it needs sorting before migration, not fixed retroactively once it’s already in the new system.
If you only do one thing properly on this list, make it this step. Clean data moving into a good system beats messy data moving into a brilliant one, every time.
Step 4: Map the fields
Your spreadsheet’s “Customer Name” column doesn’t automatically know it should become “Account Name” in the new system, and a field like “Tax ID” might need reformatting to match what the ERP expects. Someone needs to go through every field and decide where it lands, and what happens to it on the way.
This is fiddly, unglamorous work, and it’s exactly where a good implementation partner earns their fee.
Step 5: Test with a small batch first
Don’t migrate everything in one go and hope. Take a sample, maybe a hundred customer records or a month’s worth of transactions, and run it through the full process first. Check the numbers actually match on the other side before you commit to the rest.
Step 6: Run the full migration and reconcile
Once the small test holds up, move the full dataset into a test environment. Then check it properly:
- Do the record counts match between old and new?
- Do the financial totals reconcile, down to the pence?
- Do stock quantities line up?
- Are the chart of accounts and opening balances correct?
Skipping this reconciliation is how businesses end up with an ERP system that looks right but quietly disagrees with their bank statement three months later.
Step 7: Plan the actual cutover
Pick a cutoff date, ideally a month-end or quarter-end so your opening balances are clean. Stop entering new data into the old system from that point, since nothing kills a migration faster than two systems being updated at once.
Many businesses run the old and new systems in parallel for a few weeks to compare results before fully switching over. It takes longer, but it’s a lot less stressful than finding out something’s wrong after the old system’s already switched off. Have a rollback plan too, even if you never need it.
Step 8: Load the last-minute data at go-live
Whatever’s still open when you cut over (invoices raised that morning, orders placed the day before) needs to go in as its own final batch right at go-live, not weeks earlier when it was still changing.
Where Blue Lotus 360 fits in
Data migration is part of the implementation process with Blue Lotus 360, not something you’re left to figure out alone with an export button and good intentions. The team works through mapping, cleansing guidance and reconciliation with you, so the parts that need your business knowledge (which customer record is actually current, which product codes still matter) stay with you, and the technical heavy lifting doesn’t.
If you’re looking at a move off spreadsheets or an ageing system and want a clearer sense of what that actually involves for your setup, a demo is a good place to start that conversation.
FAQ Section
How long does ERP data migration usually take?
It varies with data volume and how messy the starting point is, but plan for several weeks rather than a few days, most of it spent cleaning data rather than moving it.
Can I migrate straight from Excel into an ERP system?
Yes, spreadsheets are one of the most common sources. The work isn’t the format, it’s making sure the data inside is accurate, complete and consistently structured before it moves.
What happens to my old system after migration?
Most businesses keep it accessible in read-only form for a while, useful for looking up historical records without needing it fully migrated.
What’s the biggest mistake businesses make during migration?
Skipping proper data cleansing and testing to save time. It rarely saves time in practice, since problems that would have taken a day to fix beforehand can take weeks to untangle after go-live.
