How to Change Accounting Software: A Small Business Migration Checklist

Changing accounting software should make everyday work easier. It should not leave you wondering which customer still owes money, whether opening stock was entered twice, or where last year's invoices went. A successful move preserves the meaning of your records as well as their numbers. The new system needs a clear starting point, and the old system needs a reliable place in your archive.

This guide walks through a controlled migration for a small business. It covers choosing what to move, preparing records, checking opening balances, testing daily workflows and deciding when to switch. The worked example uses a fictional business called Bridgeway Tools and fictional currency units. It illustrates checks, not journal entries to copy into a real set of accounts. Your accountant should approve accounting treatment and any tax-sensitive conversion decisions.

You can use the framework whether you are leaving spreadsheets, replacing an older desktop package or adopting a business manager app for the first time. The exact import tools will differ. Never assume that an application supports another vendor's backup file, a particular spreadsheet layout or a complete historical conversion simply because both products manage invoices.

Start with the problem you want to solve

Write down three recurring problems with your current process. For example, staff may retype customer details, the owner may struggle to find overdue invoices, and stock counts may disagree with sales records. Turn each problem into a workflow you can demonstrate in the proposed system. A feature label on a pricing page is less useful than completing a realistic task with your own requirements.

Separate necessary functions from attractive extras. A repair shop might need product and service lines on the same invoice, partial payment handling and printable receipts. A wholesaler might care more about supplier bills, stock quantities and customer balances. These businesses should not choose software from an identical checklist simply because both need accounting records.

Also identify the work that will remain elsewhere. Payroll, regulated tax submissions, specialist manufacturing and external ecommerce connections may require other tools. A migration is easier to plan when those boundaries are explicit. Do not count on a future integration to resolve a current operational requirement unless a supported solution is already available and tested.

The business management software comparison can help organize a shortlist. Use the shortlist as a starting point for trials, then verify current vendor documentation, platform support and the terms that apply to your business.

Decide how much history actually needs to move

There are several different migration scopes. You may move only master records and approved opening balances. You may also need individual unpaid invoices and bills. Or you may require detailed historical transactions inside the new system. These choices affect cost, effort, reconciliation and how staff answer questions about older activity.

Master records include customers, suppliers, product codes and account names. Opening balances describe the business at the conversion date. Open transactions explain who owes those balances and which documents remain outstanding. Historical transactions explain earlier activity. Treat these as separate layers rather than one spreadsheet containing everything.

Keeping older records in a searchable archive can be practical when the new system starts from a clean, approved position. However, confirm legal retention requirements and whether you will still have access after cancelling your old subscription. Exporting a summary PDF may preserve totals without preserving the detail needed for disputes, tax evidence or later corrections.

Xero's migration guidance discusses preparation, the amount of history involved and whether to obtain professional help. It is vendor-specific guidance, not evidence that the same conversion services exist in every product. The control schedules and Bridgeway Tools example below are original planning exercises that can be adapted to different systems.

Choose a clear cutover date and responsibilities

The cutover date divides the old records from new daily activity. A month boundary is often convenient because it aligns with regular reviews, but convenience alone should not decide it. Avoid a date when the shop is especially busy, key staff are absent or an important reporting deadline is approaching. Allow time to investigate differences before the first live trading day.

Write the boundary precisely. If the new system begins on October 1, the opening position normally reflects the approved closing records at September 30. State the timezone and final trading session if activity crosses midnight. A transaction entered later may still belong to the earlier period, so document how late supplier invoices and corrections will be handled.

Assign named people to prepare the source exports, approve accounting mappings, check customer balances, verify inventory and authorize the final switch. One person can hold several roles in a small business, but a second review of important totals is still valuable. The owner should know which unresolved issue would delay the launch.

Keep a short issue register with the source record, problem, proposed treatment, responsible person and resolution. This turns an informal collection of messages into a reviewable migration record. It also prevents the same unexplained difference from being rediscovered on every rehearsal.

Preserve the original before cleaning anything

Take a dated backup or supported export of the source system before making migration adjustments. Retain a separate untouched copy. Cleaning duplicates directly in the only source file removes the evidence you need to understand what changed. A useful archive includes both the original extraction and the reviewed version intended for the destination.

Collect the reports that support the conversion date: the trial balance where available, bank reconciliation, customer and supplier outstanding lists, inventory quantities and valuation, and relevant tax control reports. Record their report dates and filters. A report generated today for today's balances is not interchangeable with a report for the agreed historical boundary.

Test that exported documents actually open. Check a few attachments, customer statements and invoice PDFs, including older records. If access depends on the old vendor, establish how long that access lasts and who controls the account. Store sensitive exports with appropriate access restrictions rather than leaving them on a shared download folder.

The business backup guide explains why a saved file is only one part of a recovery plan. For a migration, add a manifest: what was exported, when, from which business and which software version, where it is stored, and who verified it.

Clean identifiers before changing financial values

Start with identification errors because they create confusion throughout the conversion. Two customer records may represent the same person, or similar names may represent completely different businesses. Product descriptions may have changed while the product code remained stable. A supplier's trading name may differ from its legal invoice name.

Build a mapping from each old identifier to the intended new record. Preserve the old identifier in the migration workbook even if the destination does not display it. Do not merge contacts solely because their names match. Compare available contact details and supporting transactions, and keep a record of the decision.

Standardize units deliberately. A box containing twelve items is not the same stock unit as one item. Similarly, a service sold by the hour should not quietly become a quantity measured in days. Currency, decimal precision, date format and tax-inclusive pricing need equally explicit decisions.

Clean formatting separately from accounting adjustments. Removing trailing spaces in a name is different from writing off a customer balance. The latter changes the books and requires its own approval and evidence. A migration spreadsheet should not become an unreviewed place to repair old financial problems.

Map the accounting meaning, not just matching names

Two accounts called Sales may behave differently if one system uses separate product groups, tax treatments or departments. A field called Cost may mean purchase price, average stock cost or a manually entered estimate. Read the definitions before placing source values into similarly named destination fields.

Create a mapping sheet with the source field, destination field, conversion rule and reviewer. Include examples for dates, currencies, units and tax rates. If the destination does not support a field, decide whether to retain it in an archive or use another documented workflow. Do not force unrelated information into a convenient field just to make an import succeed.

Agree on how opening equity, loans, fixed assets, accumulated depreciation and control accounts will be established. These are accounting decisions, not cosmetic setup choices. If the destination uses linked transactions to update accounts, entering both a control balance and the related documents may duplicate the amount unless its conversion workflow specifically prevents that.

For tax codes, retain the distinction between a zero rate, an exemption and an out-of-scope transaction where relevant. Their displayed amounts can all be zero while their reporting meaning differs. Have a qualified adviser review jurisdiction-specific handling instead of inferring it from the label alone.

Build an opening-balance control schedule

Bridgeway Tools agrees the following simplified opening position. The example excludes tax, depreciation detail and other complications so the arithmetic is easy to inspect. Actual migrations need the full approved set of accounts and supporting schedules, not only the categories shown here.

The schedule balances because assets of 32,000 equal liabilities of 12,000 plus equity of 20,000. That agreement is necessary but not sufficient. A duplicated invoice and an incorrect equity adjustment could still produce equal totals. Each category needs its supporting detail checked independently.

Never invent a balancing amount simply to make the destination accept the file. If the source and destination disagree, identify the difference. It may come from a missing account, sign convention, date boundary, currency conversion or duplicated opening transaction. Resolve the cause and document the correction before approval.

Bring across outstanding invoices without replaying old cash

Bridgeway's receivables comprise three invoices. Invoice A originally totalled 3,000 and has already received a payment of 1,000. Invoice B has 1,500 outstanding and Invoice C has 1,000 outstanding. The remaining customer balance is therefore 2,000 plus 1,500 plus 1,000, or 4,500.

Entering Invoice A as a completely unpaid 3,000 would overstate what the customer owes. Re-entering its old 1,000 receipt into a bank account that already includes that cash can create another error. Follow the destination's supported opening-document workflow and verify both the remaining customer balance and the bank effect.

Preserve original document references, dates, due dates and currency where the supported process allows. Staff need to recognize the invoice when a customer calls. Keep a source-to-destination reference list if the new software assigns different identifiers. A customer should not receive a confusing new demand for a document that was partly paid months earlier.

Perform the same review for supplier bills, deposits, credit notes and disputed balances. A credit balance is not automatically an error to delete. It may represent a valid overpayment or credit that must remain available. Confirm its treatment with the bookkeeper and test how it appears on a statement.

Reconcile inventory by code, quantity and value

Bridgeway has two stock codes at cutover. Product A contains 100 units at an approved illustrative unit cost of 25, giving 2,500. Product B contains 80 units at a cost of 50, giving 4,000. The inventory value is 6,500. These simplified costs are for the exercise; real valuation must follow the business's approved accounting policy.

Check each code individually. A total of 180 units does not tell you whether the right products are present. Exchanging ten units of one product for ten of another could leave the quantity sum unchanged while changing value and availability. Product codes, units and location details matter alongside the headline total.

Confirm how the destination creates opening stock. If an opening quantity is entered and old purchase bills also increase stock, the same goods may be counted twice. Historical invoices may also reduce stock again when saved as ordinary new sales. Test the conversion mechanism instead of assuming that importing history has no operational effect.

Where appropriate, perform a physical count close to the cutover and investigate differences before approval. The stocktaking guide explains a structured count process. Do not use migration day to hide unresolved shrinkage, damaged stock or unit errors inside an unexplained opening figure.

Rehearse ordinary work in an isolated test business

A balanced opening report does not prove that daily work will be comfortable. Run a rehearsal using a safe test environment that cannot send real customer messages or overwrite live records. Test representative tasks rather than only the easiest sale. Include a service line, a partial payment, a supplier bill, a return or correction, and a printed or shared document where relevant.

For Bridgeway's simple stock test, sell two units of Product A at 40 each and receive the full 80. Starting from the example opening position, the bank would become 12,080 and Product A would have 98 units, assuming no taxes, fees or other movements. At the illustrative cost of 25 per unit, total stock value would become 6,450. These are expected test outcomes, not instructions for a particular product's accounting engine.

Check the customer balance, stock movement, invoice output and relevant reports after the test. Then test a supported reversal or correction and confirm what changes. A staff member who can create an invoice but cannot safely correct a mistake is not ready for a busy trading day.

Record results with the exact app version and configuration. If a later setting change alters tax calculation or document numbering, repeat the affected checks. Avoid connecting test data to the production synchronization account or leaving test invoices mixed with real opening documents.

Plan the final switch and a realistic fallback

Before the final conversion, decide which system is authoritative for each period. Running two independent live books without a strict reconciliation plan increases the chance of duplicate invoices, missing receipts and conflicting stock quantities. A short observation period can be useful, but staff still need one clearly defined place to enter real transactions.

Prepare a cutover checklist with the last source backup, final exports, approved balances, destination verification and launch authorization. Keep evidence of each completed check. If a critical difference remains unexplained, delay the switch rather than treating the deadline as proof that the records are ready.

A fallback plan needs more than the phrase restore the backup. Once new sales and payments have occurred, restoring an earlier database can erase them. Define who can decide to revert, how post-cutover activity will be preserved, and how those transactions will be entered into whichever system becomes authoritative. Test the recovery process beforehand where possible.

Keep source subscriptions or licenses available for the planned review window if necessary. Confirm cancellation timing, export access and record retention before closing anything. The cost of a short overlap may be easier to manage than losing access to evidence that the migration still needs.

Moving to Yesri without assuming an unsupported importer

Yesri's documented setup covers business profiles, customers and suppliers, inventory, banking, invoices, purchases and reports. Start with the getting started guide, then work through the modules your business actually uses. Establish a small test business first and verify the current version's available fields and behavior.

This article does not claim a general spreadsheet importer, an automatic conversion from another accounting product or a guaranteed complete historical migration. If you require one of those capabilities, confirm support before committing. A file from another vendor does not become a Yesri backup by changing its extension.

Use the customer and supplier guide, inventory guide and banking guide to prepare accurate starting records. Agree with your accountant how approved opening balances and outstanding documents should be represented. Ordinary transaction entry can affect stock and accounts, so avoid entering historical activity twice through different setup paths.

Yesri file restore is a separate operation from migrating another application's records. The backup documentation describes its replacement behavior. Protect the destination before restoring a supported backup, and do not treat restore as a selective merge. Similarly, read the desktop synchronization guide before connecting devices; synchronization is not a substitute for conversion checks or a historical archive.

Review the first week before calling the move complete

Compare the first day's invoice sequence, receipts, supplier payments and stock movements with supporting documents. Ask staff where they paused or repeated work. A small usability problem identified early can become a large recordkeeping problem if everyone invents a different workaround.

During the first week, review overdue customer balances and upcoming supplier bills. Confirm that due dates survived the move and that reminders refer to the correct outstanding amounts. Check that document templates show the intended business identity and contact details. Never assume that a correct balance means every customer-facing field is correct.

At the first month end, reconcile the bank and review the full reporting period with the bookkeeper. Use the month-end close checklist to organize evidence and unresolved items. Preserve the migration issue register alongside the opening schedules so later reviewers can understand decisions without reconstructing them from memory.

Close the migration only when the agreed acceptance checks pass, responsible people approve the result, and the archive and recovery plan are usable. Keep a short handover document explaining where to find historical records, how to report an error and who maintains backups. The project ends when the business can operate and explain its records confidently.

Frequently asked questions

Must I move every old transaction?

Not always. A supported opening-balance conversion with detailed outstanding items and a reliable historical archive may meet operational needs. Retention obligations and reporting requirements still apply. Decide the scope with your accountant and verify archive access before cancelling the previous system.

Can I switch software halfway through a year?

It may be possible, but the opening position, year-to-date reporting and tax treatment need a coherent plan. A clean month boundary can simplify review without removing those requirements. Choose a date that your team and adviser can support rather than assuming only the year end works.

Is a balanced trial balance enough?

No. Matching debit and credit totals do not establish that every customer, supplier, product or bank item is correct. Review the detailed supporting schedules and test real workflows. Equal totals can hide offsetting errors, duplicate documents or incorrect dates.

What if my new software cannot import a needed field?

Pause and decide how that information will be retained and used. An approved archive or documented manual workflow may be suitable for some fields. A missing essential operational capability may mean the product is not a fit. Do not silently discard information that staff or legal records require.

Your next practical step

Create a one-page migration brief containing the business problems, required workflows, proposed cutover date, historical scope and approval owners. Attach an inventory of source exports and a list of unresolved questions. This makes a trial specific enough to expose gaps before you move live data.

Then rehearse with a small representative dataset and write down expected outcomes before entering it. Compare actual balances, stock and documents against those expectations. A careful migration gives the new software an explainable starting point and gives your team a dependable way to work from the first day.