Migrating your data to aACE may feel like a daunting task. While there are many moving parts in the process, staying focused during each stage will help the migration run smoothly. This guide will help you understand how all the moving parts work together to bring the system up to a fully functional state.
Data Types
There are two types of data in aACE — master data and transactions:
Master data includes data that is required to successfully complete a transaction. Master data should always be migrated prior to go-live, and the process is fairly straightforward. Master data includes:
- Offices
- Team Members (employees)
- GL Accounts
- Line Item Codes (products / services)
- Companies
- Contacts
Transactions include data involving money. Migrating transactions requires more planning and consideration. Transactions include:
- Orders
- Invoices
- Receipts
- Purchase Orders
- Purchases
- Disbursements
- General Journal entries
The remainder of this guide focuses on the possible strategies for accomplishing your data migration.
Go-Live Strategies
A go-live strategy can follow either of these two approaches, each of which will impact the data-migration requirements:
- Shuttle launch approach
- Phased launch approach
The Shuttle Launch Approach
The goal of the shuttle launch is to have a clean break between your old system and aACE. With this approach, you stop using your existing system on a Friday and begin using your new system on a Monday. This is the cleanest option with regards to data, but this option requires the most preparation because it can be the most jarring to users.
For the shuttle launch approach to work successfully, the data on Day 1 has to support your users' daily activities. It is important to identify every user's daily activities and ensure both that the migrated data supports their daily activities and that the users are sufficiently trained to perform their daily activities. This does not necessarily mean that 100% of historical data has to be imported, but it does mean that all records affecting your daily operation are imported. For example, open invoices must be imported so the A/R staff can pursue collections.
The Phased Launch Approach
The goal of the phased approach is to gradually reduce reliance on your existing system until it can be fully deprecated in favor of aACE. However, for the phased approach, you need to decide whether aACE or your existing system will be the accounting system "of record". With this approach, you start using aACE for new transactions and only use your old system for old transactions. This is often the easiest approach for users, but it requires some amount of data synchronization.
If your existing system is to be used as the system of record, you will need to make general journal entries there to reflect the activity in aACE. If aACE will be the system of record, general journal entries will be needed in aACE to reflect the accounting activity in your existing system. We recommend that these entries be made at least monthly.
Most users prefer to keep their existing system as the "accounting system of record" for the first several months. This gives the accountants an opportunity to audit aACE before switching the bookkeeping system.
There are just a few final steps to take before you make the final switch:
- Make sure there are no open transactions in the existing system that are not also in aACE. If there are, recreate them in aACE.
- Zero the accounting balances in aACE as of the designated switch date.
- Enter a beginning balance entry that syncs the two systems' books as of the designated switch date.
- Cease use of the existing system.
Ways to Make the Process Easier
There are a number of ways the migration to aACE can be made easier. Here are some ideas to consider:
Postpone a Full Data Migration Until After Go-Live
The presence of historical data can be advantageous for reporting, but the data can itself introduce errors. It is often much easier for users to begin using a system without historical data in it. Doing a full data migration prior to go-live requires substantial amounts of testing, often from users who are either A) not very familiar with the data (your aACE partner), or B) not very familiar with the system (your team).
For these reasons, it is worthwhile to consider importing the historical data several months after go-live. If this strategy is employed, aACE records should be given high starting IDs such that historical records can be imported at a later date, but still appear in chronological order when sorted by their ID.
Migrate Only the Historical Data for Comparative Reporting
If historical sales data can be imported exclusively into the Invoices module, then importing orders may not be necessary. Likewise, if historical purchase data can be imported exclusively into the Purchases module, then importing purchase orders may not be necessary.
If payments/credits against invoices can be imported as a negative line item into the Invoices module, then importing receipts may not be necessary. And finally, if payments/credits against purchases can be imported as a negative line item into the Purchases module, then importing disbursements may not be necessary.
With proper planning and careful attention to the details, your migration to aACE should run smoothly.