How to plan a migration to Sage in the UK

A Sage migration is rarely a technical problem on its own. The software is the easy part; the difficult part is deciding what data deserves to move, proving that it arrived correctly and switching your people over without missing a VAT return or a pay run. This page is written for finance directors, financial controllers and IT leads in UK SMEs who are about to move to Sage or migrate to Sage from something else, or who need to move between Sage versions.

It sits alongside our general guide to ERP migration and the wider view of ERP implementation with Sage.

Which kind of Sage migration are you facing?

The word "migration" covers very different projects. Naming yours correctly is the first step, because the risks, the effort and the right kind of integrator differ.

If your plan is to move from one Sage product to another, start with the Sage versions and editions page so you know what each family is designed for before you plan the data work.

What the publisher provides, and what it does not

Sage supplies import and conversion utilities for some routes, and each product has its own data import templates and documentation. Which of them apply depends on your source system, your edition and the exact version. We do not list tool names or limits here, because they change between releases and an out-of-date claim would mislead you.

Treat the publisher's tools as a way to load data, not as a migration plan. They will not decide which accounts to merge, which customers are duplicates, or how your analysis codes should look in the new system. That work belongs to your team and your integrator, and it is where most of the time goes.

What data to bring across

The best question to ask is not "what can we move?" but "what do we need to run the business and satisfy HMRC and our auditors?". A useful way to sort it:

• Master data: customers, suppliers, products, price lists, bills of materials where relevant, bank accounts and the chart of accounts.
• Open items: unpaid sales and purchase invoices, open orders, goods received not invoiced, and stock on hand by location.
• Opening balances: trial balance at the cutover date, fixed asset register with depreciation positions, VAT and payroll liabilities.
• History: summarised prior-period figures for comparison, plus detailed transactions only where you truly need them for queries or analysis.
• Documents and attachments: scanned supplier invoices, contracts and approvals, if your process needs them in the new system.

Detailed historical transactions are often better left in an archive. Keep it readable, protected and documented, and check your retention duties with your accountant before you decide what to drop.

Payroll and employee records

Payroll deserves its own track. Opening balances must reconcile to what has already been reported through RTI, and year-to-date figures have to be right for the first run in the new system. If payroll is in scope, read payroll software and RTI and plan the switch with your payroll bureau or internal team. The Sage payroll and HR page explains how this area fits into the wider platform.

Cleaning the data before it moves

Cleaning is cheaper before the load than after. Plan time for each of these:

1. Remove duplicates in customers, suppliers and stock items, and decide which record survives.
2. Close dead accounts: inactive customers, suppliers you no longer use, obsolete items and unused nominal codes.
3. Standardise formats: addresses, postcodes, VAT numbers, units of measure and naming conventions.
4. Fix the chart of accounts: agree with your accountant what the new structure should be, including cost centres or departments for management reporting.
5. Reconcile first: bank, VAT, stock valuation, debtors and creditors should agree with the ledger before any extract is taken.

A load of dirty data only produces a dirty system faster. Your integrator should run a profiling pass on a copy of the data and give you a list of anomalies to resolve before the first test load.

Mapping and test loads

Mapping is the document that says where each field in the old system lands in Sage. It should be written down, reviewed by the business owner of each area and kept under version control. Typical decisions include how to translate old account codes, how to treat multi-currency balances, and how to represent VAT codes so that returns are correct under Making Tax Digital.

Plan several test loads, not one. A sensible rhythm is:

• A first load to find structural problems and rejected records.
• A second load with corrections, followed by reconciliation reports signed off by finance.
• A dress rehearsal that follows the exact cutover script, including timing and the order of steps.

Each load should end with a reconciliation: totals by ledger, counts of records, ageing of open items, stock valuation and a handful of random transactions traced by hand.

Choosing a cutover strategy

There is no single right answer. The choice depends on your risk tolerance, your seasonality and the size of the project.

Most UK companies pick a period or year end for the financial opening, then decide separately whether operational processes switch on the same day. Whichever you choose, check the calendar for VAT return dates, payroll runs, quarter-end reporting and any audit fieldwork, and keep your Making Tax Digital submissions working without interruption.

Testing before you go live

Testing is where migrations are won or lost. Insist on more than a technical check.

• Reconciliation tests: do balances, ageing and stock valuation match the source?
• Process tests: can a user raise an order, receive goods, post a supplier invoice, run a payment run and close a period?
• Compliance tests: do VAT calculations and returns, payroll submissions and any e-invoicing needs behave as expected?
• Integration tests: do banks, e-commerce, CRM and other connected systems exchange data correctly? See Sage integrations for the usual connection points.
• Report tests: can the finance team produce the management pack and statutory figures they depend on?
• User acceptance: the people who will do the work, not the project team, sign off the scenarios.

Document defects, decide which block go-live and which can wait, and have the business owner, not the supplier, take the go or no-go decision.

Preparing people

A good load can still fail if people do not know how to use the new system on the first Monday. Schedule Sage training before cutover rather than after it, and plan extra support for the first period close, the first VAT return and the first payroll. Name a small number of super-users in each department who can answer questions quickly.

The rollback plan

A rollback plan is a document you hope never to use. It should cover:

• The point of no return: after which events going back becomes impractical, for example after the first payroll or the first customer statements are issued from Sage.
• Backups: verified copies of the source system and of Sage before each load, with a tested restore.
• Read-only access: the old system kept available for queries and, if needed, for resuming work.
• Decision rights: who decides, on what evidence, and how quickly.
• Replay method: how transactions entered in Sage would be re-entered or exported if you have to return.
• Communication: how customers, suppliers, your bank and your accountant would be told if the date moves.

If your project is already struggling, an independent Sage audit and project rescue can tell you whether to continue, pause or reset before the go-live date arrives.

Hosting and environments

Decide early where Sage will run, because it affects the migration environment, performance of large loads and your backup approach. Read Sage hosting and cloud and our guide to cloud and on-premise ERP before you agree on the target environment.

Common mistakes to avoid

• Moving everything "just in case", which imports years of junk and slows testing.
• Skipping the mapping document and relying on the person who built the extract to remember what they did.
• Leaving the accountant out until the opening balances do not agree.
• Testing only the load, not the processes people will run on the first day.
• Choosing a date for the supplier's convenience rather than around VAT, payroll and trading peaks.
• No named owner for data quality in the business.
• Underestimating the first month, when corrections, questions and period close all collide.
• No rollback plan, or one that nobody has read.

Our guide on ERP project mistakes goes further into why projects drift.

Finding the right integrator for your migration

A migration needs someone who has done your type of move before: the same source system, the same Sage product and a similar business model. Ask for a data approach, a cutover proposal and a testing plan before you sign anything, and check that they will work with your accountant. Our page on choosing a Sage partner lists the questions worth asking, and Sage in the UK explains the local context.

ERP Integrator is a free matching service: you describe your project, and we put you in touch with an integrator suited to it. We are not affiliated with Sage, and the migration itself is carried out by the integrator you choose. You can see how the matching works before you submit a request.

Software names mentioned are trademarks of their respective publishers and are referred to for information only. This site is independent and is not affiliated with any software publisher.