Understanding the aACE data migration process

Migrating your data to aACE can initially feel like a daunting task. While there are many moving parts in the process, staying focused during each stage will help make the migration run smoothly.  This discussion 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: "entities" and "transactions". Entities include data that is required to successfully complete a transaction. Transactions include data involving money.

Entities include: 

  • Offices 
  • Team Members (employees) 
  • GL Accounts 
  • Categories (products / services) 
  • Companies 
  • Contacts

Transactions include:

  • Orders 
  • Invoices 
  • Receipts 
  • Purchase Orders 
  • Purchases 
  • Disbursements 
  • General Journal entries

Entities should always be migrated prior to go-live, and the process is fairly straightforward.  Migrating transactions, however, requires more planning and consideration. There are multiple strategies used to accomplish this task, which is the focus of the remainder of this document.

Go-Live Strategies

There are two approaches to choose from for a go-live strategy: the Shuttle Launch Approach and the Phased Launch Approach. The type you employ will have an impact on the data-migration requirements:

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 beginning 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, ensure 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 which system will be the accounting system "of record": aACE or your existing system. 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 used, general journal entries will be needed in aACE to  reflect the accounting activity in your existing system. We recommend 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. They are: 

  1. Make sure there are no open transactions in the existing system that are not in aACE. If there are, recreate them in aACE. 
  2. Zero the accounting balances in aACE as of the designated switch date. 
  3. Enter a beginning balance entry that syncs the two systems' books as of the designated switch date. 
  4. 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 (us), or B) not very familiar with the system (you).

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. 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. 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.

 See Also

Migrating entity data to aACE

Have more questions? Submit a request
Powered by Zendesk