Insights & Resources
Expert guides, product updates, and industry trends from HelloBooks. Browse articles on accounting, compliance, bookkeeping, and financial management for small businesses.
Accounting
How To Migrate From Wave Accounting
Expert guides, product updates, and industry trends from HelloBooks. Browse articles on accounting, compliance, bookkeeping, and financial management for small businesses.
HelloBooks.AI
13 min read
Got questions?
A hands-on guide to exporting, verifying and switching with confidence
Moving accounting information from one system to another can seem like an overwhelming task, but with a sound strategy and a gradual approach you will be able to move your accounting records over successfully which will enable you maintain financial continuity. This guide explains all the elements you need to cover: planning, preparing exports, cleaning and mapping data, importing into the new system, reconciling balances and validating results before you shut down full-bore accounting operations.
Well, you can start to define its boundaries in terms of scope, timeline and parties involved. Determine what records to transfer: chart of accounts, customers and vendors, opening balance, invoice, bill, payment or bank transactions and historical reports. You should make a choice; whether you want full historical migration or just last periods. Pick a migration date and create a detailed timeline that covers backups, export windows and trial period.
Summary Since the data is highly sensitive, you need to ensure compliance with any applicable sectors and/or industry regulations governing retention, access, and transfer of financial records. Engage your legal and compliance teams early to ensure an understanding of how long you need to retain records, what documents must be handled securely, and whether you will have to mandate encrypting transfer or ask for a guesthouse. Note the decisions you made regarding jurisdictional storage — especially if the destination system or backups will exist in another country — and maintain proof of custody for sensitive documents or records for tax purposes. Keep a checklist of the controls, along with evidence that they have been implemented before you decommission the source to attached to your migration log so that compliance reviewers can confirm that each control is in place.
Check with your national tax authorities for retention policies.
Use encryption for transfers, and secure file channels.
Log access and changes to exported files.
Audit jurisdiction and backup locations.
Remove source once legal has signed off.
Prior to transferring any data, securely backup your source system data. Export lists of accounts, transaction exports, and reports. -Verify that you're exporting with an appropriate level of admin and the credentials in use for export are securely stored. The safest migrations begin with a recoverable snapshot for rollback, if necessary.
Leverage the export capabilities of your source system to export data in widely accepted formats like CSV, Excel, or XML. The most common exports are Chart of Accounts, Customers, Vendors, Items or Services, Invoices, Bills, Payments (Suppliers), Credit Notes (Customers & Suppliers), Opening Balances and Bank Transactions. Include transaction date, reference numbers, descriptions, tax code and amount when exporting. Document export settings and file versions to a migration log, so that you can follow what was migrated at which point.
Determine what transactions need to be migrated and what historical records can remain offline archived as keeping every transaction could add to migration time, storage expenses as well as reconciliation complexity. Design an archival schema that associates archived files with ledger periods, customer or vendor identifiers, and document references so they can be restored or referenced without bringing them back into active ledgers. It can use compressed, read-only formats with cryptographic checksums and index files for fast retrieval, as well as prove integrity in the case of an audit. Establish retention timelines for them, criteria for what to delete when the time comes, as well as a retrieval process that provides role and SLA targets so archived data complements legal requests and business analytics without bloating the live environment.
Establish well defined cut-off dates for migration.
Indexed archives using metadata tags.
Archive to immutable storage with checksum.
Test annual retrieval of archival material to confirm that it is retrievable.
Storage costs and policies Documentation.
Open the exported files and look for anomalies: perhaps some fields are missing, there might be duplicates, dates or currency codes may not match. 5) PrettyClean - It will combine customer/vendor from the same address code and remove unwanted as test data grants. Correct export file blatant errors to minimize problems on imports. Otherwise, you may need to normalise dates and currencies as well as the account names in terms of what format the destination system exposes.
Record transaction currency, applicable exchange rates and conversion methods as of posting so historical figures can be recreated. Import both the natively denominated amounts, as well as the equivalent in functional currency where possible to ensure auditability and ease of subsequent reporting. This ledger allows the posting of currency gains or losses to be separated out so they don't distort prior income statements in the target system. If your new system rounds differently, test the outputs against a sample set to identify differences and provide acceptable tolerances.
Original currency fields & Total converted per transaction.
Store historical conversion rates with timestamps and official references.
Monthly / quarterly reconciliation of multi currency ledgers and currency revaluation entries.
Rounding and posting rules tests on representative sample batches.
Track escalations and approvals of acceptable variance thresholds for the record.
Mapping is the most important thing. Compare or document source and destination chart of accounts - generate an account code/name mapping table. Similarly, customer/vendor fields, tax codes, invoice number/payment method formats should also be mapped. Record these mapping in an Excel sheet for refreshing or modifying the import consistently.
By maintaining original timestamps, user identifiers and any system-generated IDs when migrating records, audit trails remain intact and accountability is traceable. For certain metadata fields the destination system may not be able to store, such data should be stored on an attached immutable log referencing ledger entries and queryable on an audit basis. Keep track of all transformation rules and mappings in one file applied such that any auditor can reverse migrate the dataset to data in its original form. Migrate with external storage on path filesystem note lot help make migration successful.
Maintain original timestamps and user IDs in logs.
Audit refers to exporting rejected rows along with the reason for rejection.
Add manifests with checksum and signer.
System original IDs preserved as reference fields.
Give the auditors a migration reconstruction guide.
Opening Balances Import effectively by setting opening balances in the destination so that your trial balance is good after import. “But the invoice is still outstanding” – How did you migrate the open items to SAP? Request a vendor/customer balance confirmation from the legacy systems As part of our go live activities, I maintained an upload in LSMW Transform SW which replicates transaction type, amount and clearing/balance fields. Balance bank and credit card statements to ensure the total of imported transactions is equal to the statement. Perhaps you will want to import a short interval of past transactions on both sides to check that the continuity is correct.
If you can, try it out on a sandbox or test version of the destination system. First, import a working set of data: some fellas, some invoices and maybe part of the transactions. Ensure that field mappings, tax treatments and posting down are in accordance with expected behavior. Use the migration log to monitor files that were imported and for any errors or warnings generated during an import.
Huge imports can overwhelm the destination system or set off throttles, so pace batches to available system capacity and maintain service levels for other users. Use parallelism where safe, while not violating referential constraints or posting rules that require entries to be made in a given sequence. Yes, and validate files on a pre-import basis so poor formatting or data quality does not waste costly imports (also keep a retry queue for transient failures). Use CPU, memory and database locking data from test imports to identify bottlenecks and scale batch sizes/thread counts/transaction sizes.
Low usage windows with monitoring on imports.
Changing test run based on throughput of batch size.
Minimize locks: use transactions and commit intervals.
Minimize payloads, strip out unnecessary fields before.
Measure elapsed time per batch and tune concurrency.
Once testing is successful, Imports should be run in logical groups: Lists (chart of accounts, customers, vendors), opening balance, transactions (invoices, bills and payments) and bank feeds or reconciled bank txns. Using this order avoids having to make as many manual modifications, and facilitates keeping the keys all in synch with one another.
When native export/import tools cannot fill the gaps, do think of writing middleware that reads from source API, transforms according to defined mappings and writes to destination API with retries and idempotency. Middleware enables you to impose business rules in transit, combine records, and divide them with real-time referential integrity. Throttling and bulk endpoints help avoid limits on the number of requests per second or minute. Logs every API transaction correlating it with migration identifiers to help troubleshooting and allow safe retries without creating duplicates
Use idempotent POSTs and record source IDs.
Automatic exponential backoff on failed requests.
For large uploads: Use bulk APIs.
Validate transformations before records are sent to the destination.
Match Logs to Migration Batch IDs.
users: Run TB and aged A/R, A/P reports in the target systems and compare to those from source on data cut-off date. Make sure totals agree and major balances such as retained earnings, equity accounts, bank account balances, tax liabilities also reconcile. Cleaning loose ends on the source is a good place to start – Identify and resolve any discrepancies before you turn off the source system.
This means organizations need to identify all integrations that rely on source accounting data (for example, payroll, inventory, point of sale, payment processors or tax engines) so interfaces can be updated or reconnected. For third party vendors, + Coordinate cutover with them ensuring that API keys, endpoint changes and any anticipated adjustments in data formats are agreed upon. Run parallel feeds for a limited time to verify downstream systems receive correct payloads, and that workflows like payroll runs or supplier payments are unaffected. Get easy access to document integration points, schedules and owners in order that issues can be escalated quickly (and fixes deployed without disrupting business operations).
Take an inventory of all connected systems and their respective owners.
Check on API versions and authentication methods.
Vendor tests on critical transactions.
Offer rollback endpoints to vendors if problems manifest.
Create high-level training and cheat sheets for teammates who will use the destination system. Focus on daily processes — posting invoices, recording payments, reconciling bank accounts — to get back up and running. Design for a rolling go-live where both systems may be referred to then pick a distinct cutoff date by which all new transactions need to have been entered in the destination system.
Implement automated checks on p95 and p99 SLAs as well as SLIs, to ensure that their quantitative values stay within bounds of expectations across all stages of migration. These include checks for discrepancies in the trial balance, missing customer balances, duplicated transactions and reconciliations that can not be adjusted within a specified window. (If rollback is needed, prepare scripts or automatic processes to undo imported batches, restore from backup and bring up the legacy system for a controlled rerun. Allocate decision rights, communication steps and time to resolution estimate so stakeholders can inform critical choices under pressure.
Numeric thresholds that halt automated immediately.
Locally store tested restore scripts and snapshots.
Specify who can authorize a rollback after.
Inform all ops teams of contingency measures.
Log data loss estimates and how to resync.
After go live, be vigilant in validating the first few reporting cycles. Balance bank accounts and process month-end reports for reconciliation to anticipated results. The migration logs and backups would reside for a number of days based on your internal retention policy. Correct user questions and iterate on mappings or templates if you notice the same pattern re-occurring.
Develop a communications plan that specifies what and — when people need to be informed — the level of detail so that internal teams and external partners are as little surprised by the situation as possible. Provide daily status updates during the critical migration time period, and have a run book for cutover day that clearly communicates roles, contact lists, escalation paths. Plan for comprehensive staff coverage through finance, IT and support for the first few business cycles post-go-live to ensure timely issue resolution. Broadcast the scheduled downtime to customers and vendors along with potential impacts and support channels as well as instructions for fallback.
Release schedules, expected impacts and support contacts to the public.
Fear of missing out (FOMO) get it from multiple channels from email to dashboards and sms alerts.
Conduct a pre-cutover rehearsal with all owners in attendance.
Keep a record of decisions made and final postmortem published.
Incomplete exports: Ensure all the fields and date ranges required are being exported before you get started Poor mapping documentation: Keep a single mapping document updated as changes are made Skipping tests Always test with a sample import to catch format mismatches early Ignoring reconciliations Reconcile balances through migration if you don’t want surprises at month end.
vWe automate, all these checks run post-batch and compare totals, counts and key balances on source system snapshots preventing regressions from getting to production quickly. Monitor critical KPIs like data latency, reconciliation pass rates, exception volumes and user access issues so that you can prioritize fixes. Within the initial months after a migration, prepare to schedule regular audits to validate reports and tax positions, as well as make necessary updates for mappings or transformations. Supplier-based incorporation of migration logs, import manifests and backups have to be kept on hand for the audit team as well as forensic analysis in case differences will show up at a later stage.
Daily automated end-to-end post batch reconciliation checks
Track reconcile pass rate and alert drift
Monitor exception volume and assign owners at the earliest
Regularly checkbooks and verify financial statements
Maintaining logs and manifests available for auditors
A considerate migration that minimizes risk to the business and allows for continuity of operations. By planning, testing, and validating each step — especially data export, mapping and reconciliation — you’ll minimize errors and gain confidence that your financial records are accurate through your transition (and after). Use this timeline as a model, for your organization may have to modify these action items based on your company’s size, amount of transactions or reporting you need to fulfill.