Data Migration Plan: A Guide for Australian SMBs

What data migration actually involves

Data migration is the work of moving records out of one system and into another so they stay usable. Your accounting package changes. A shared drive that has been quietly filling up since 2014 moves into SharePoint. A CRM built from spreadsheets gets replaced by something with an audit trail. In every case a vendor sells you the destination, and somebody still has to get a decade of your business into it.

The part that catches owners out is scope. A migration is rarely one export and one import. Most Sydney businesses we work with are moving four or five overlapping sets of data at once, and each set has its own owner, its own quirks, and its own idea of what a complete record looks like.

• •Transactional records: invoices, purchase orders, job cards, timesheets. High volume, strict formats, and usually the reason you have a deadline.
• •Relationship data: contacts, accounts, sites, opportunities. Low volume, high political value, and full of duplicates.
• •Documents: quotes, contracts, site photos, signed variations. The bulk of the storage and the hardest thing to validate.
• •Configuration: users, permissions, tax codes, price lists, workflow rules. Small, fiddly, and the reason day one goes badly when it is skipped.
• •History nobody owns: the departed sales manager's mailbox, the archive folder on the old server, the Access database in accounts.

That last category decides whether a project runs to plan. Nobody budgets for it because nobody can describe it until they open it.

Where these projects go wrong

The failures repeat. After enough of these you stop being surprised by any of them.

Trusting the export

Legacy systems lie about what they will give you. A CSV export drops attachments. An API caps a description field at 255 characters and truncates without warning. Custom fields that a previous staff member added come out with meaningless labels. Run a full export early, open it, and count what came back against what the old system says exists.

Migrating the mess

If four versions of the same client sit in your current database, you now have four versions in a system you are paying more for. A migration is the one moment when cleaning up is cheap, because the data is already being handled.

Nobody owns the sign-off

IT can confirm that 14,382 rows moved. Only your accounts manager can confirm that the aged receivables report matches. When no business owner signs off on a data set, errors get found by customers.

The old system gets switched off too early

Somebody cancels the licence to save money in the first month. Then a dispute lands that needs a job record from 2021, and the only copy is in a database format nothing can read. Keep read-only access for at least a year, or take a full export and store it somewhere you can actually restore from.

Cutover lands on the worst possible week

End of month, end of financial year, or the Monday your operations manager starts two weeks in Bali. Pick the quietest week you have and protect it.

Build the plan before you touch the data

A workable data migration plan fits on a few pages. It does not need project management software. It needs decisions written down where people can argue with them before the work starts.

• •An inventory. Every system holding business data, who owns it, roughly how many records, and how far back it goes. Walk the office and ask. You will find things that are not on any asset list.
• •A cut line. Decide what moves and what stays behind in an archive. Seven years of closed jobs rarely needs to be live in the new platform.
• •Field mapping. A spreadsheet with the old field on the left and the new one on the right. Blank cells on either side are the real work of the project.
• •Named owners. One person per data set who will personally look at the result and say yes.
• •A rollback position. What happens if Thursday's load is wrong, and how long you can run on the old system while you fix it.

Field mapping is where a data migration strategy stops being theoretical. The old system has one address field. The new one has street, suburb, state, and postcode as separate values. Somebody has to decide how 6,000 messy address strings get split, and whether a script does it or a person does. Answer that question in week one, not the night before cutover.

Clean the data first, and be ruthless

Cleaning before the move costs less than fixing afterwards, because once records are live your team starts editing them and you lose the clean comparison point. Give yourself a fortnight and work through a short data migration checklist with the people who use each set daily.

• •Merge duplicate customers and suppliers, and agree on which record wins before anyone starts clicking.
• •Deactivate contacts who left their company years ago rather than importing them and hoping.
• •Standardise phone numbers, ABNs and state codes so the new system's validation does not reject a third of your file.
• •Find the records with missing mandatory fields and decide on a default now.
• •Delete the personal data you no longer have a business reason to hold. A migration is a good moment to shrink your exposure.

Plenty of this can be scripted. Data migration tools built into platforms like Power Platform, or a well-written set of transformation rules, will handle deduplication and field splitting far faster than a temp with a spreadsheet. The judgement calls still belong to your staff. Our integration and automation team usually builds the transformation once, runs it repeatedly against test loads, and lets the business owners focus on reviewing exceptions.

Test twice, then test with the people who use it

Run at least two full rehearsals into a test environment before the real thing. The first tells you what breaks. The second tells you whether your fixes worked, and gives you a realistic figure for how long the load takes, which is what your cutover weekend is built on.

Useful data migration testing goes past row counts. Reconcile totals that the business already trusts: aged receivables, stock on hand, open jobs, leave balances. If the new system disagrees with the old one by $40, find the $40. Then hand the test environment to five staff and ask them to do their actual job in it for an afternoon. They will find the broken things that no report exposes, like attachments that came across as filenames without files.

The migration is not finished when the data lands. It is finished when the person who relies on that data agrees the numbers are right.

Write down what "right" means for each set while you still have both systems running. A reconciliation you can repeat is worth more than a one-off inspection, because you will want to run it again after cutover.

Cutover week and the 90 days after

Cutover is a sequence, so write it as one, with times against each step and a name beside each line. Freeze changes in the old system at a stated hour. Take the final export. Load it. Run the reconciliation. Have the owners sign off. Then open the new system to everyone, and no earlier.

Build in a decision point. If reconciliation fails at 9pm Saturday, does the business open Monday on the old system or push through? Decide before the pressure, because the answer at 9pm on the night is almost always the wrong one.

Tell your customers and suppliers what is happening if the change touches them. Invoice numbers that restart, a new remittance address, or a portal login that stops working will generate phone calls you can avoid with one email sent a week in advance. Give your front desk a short script for the questions that will come anyway, and let your account managers warn their larger clients personally.

The first fortnight afterwards matters more than the weekend itself. Expect a spike in support requests that has nothing to do with the data and everything to do with people not knowing where things are. Keep the old system readable. Run your reconciliation again at day 30, once real transactions have flowed through, because problems with the data migration process often only appear when a month-end report goes looking for something. If you run with an internal team, a managed IT service can absorb that support spike so your own people stay on the reconciliation work.

The Australian compliance angle

Moving personal information does not suspend your obligations under the Privacy Act 1988 and the Australian Privacy Principles. A few practical points apply to almost every Australian business doing this work.

• •Know where the new system stores data. Many platforms default to offshore regions. Check whether yours offers Australian hosting, and confirm it before go-live rather than after.
• •Protect the working copies. Extract files sitting on a laptop or an unsecured share are a soft target. Encrypt them, restrict access, and delete them when the project closes.
• •Respect retention rules. The ATO expects most business records to be kept for five years, and Fair Work requires employee records for seven. Archiving is fine, deleting because it was inconvenient to move is not.
• •Rebuild permissions deliberately. A SharePoint data migration that flattens folder permissions can quietly expose payroll to the whole company. Check the resulting access model, not just the file count.

The permissions point deserves attention. Old file servers accumulate access rules that nobody has reviewed since the person who set them up left. Moving to a new platform is your chance to rebuild that model on purpose, which is worth doing alongside a broader security review while you have everyone's attention.

None of this makes a data migration exciting. It does make it boring, and boring is the outcome you want. The businesses that come through these projects without drama are the ones that spent the first three weeks arguing about field mappings and sign-off, then executed a plan they had already rehearsed.

This article reflects best practices as of the publication date. Technology and security recommendations evolve, so verify current guidance with the original sources or our team before acting.