Often one of the difficult conversations in the implementation of a new systems is what do I do with the legacy systems. The conversations circles around a number of topics.

• Reference purposes. Business users need to have access to the data for reference purposes in the future.
• Regulations. Most countries have tax or company legislation that require companies to keep access to records for 5-7 years and in some cases longer like 10 years. Most companies keep an accounting system for this amount of time so good chance this is your only record of data unless you have printed and archived paper financial statements, trial balances, sub-ledger details reports on a regular basis over that time.

Reference Purposes

You want to have all the business teams sit down and assess their functional areas and evaluate critically what data they really need access to going forward. You might want to do some statistical analysis on how often the data is access. Things to look at:

• General ledger. How much detail does the finance team want in the general ledger. Likely they want balance history for at least the previous year to be able to run reports as a prior year comparison. These balances can often be extracted and moved into excel spreadsheets. Once there the finance team can use them with Management reports and new data accumulated in Dynamics AX to create reports on prior to current.
• Accounts Receivable. What is the typical debt aging you use. If you manage to a 60-90 days then good chance these users will only need to look at invoice history for another quarter so keeping the legacy system accessible to a small number of users for the first quarter after go-live in the new system will avoid having to migrate data and after a quarter you will have the relevant history built up in the new systems. If you have debts outstanding for 90-180 days considering to an analysis of how many customers are actually in this range. If it’s only a small number of customers consider doing some list extraction for reference purposes to avoid having to migrate the data or keep the old system running for a long time.
• Sales. Do you have long quoting or sales cycles? Is there a need to keep price history. Most of these can either be extracted in data migration for open. Prices have date effectivity in AX so you could migrate old prices but consider how much you really need them to avoid spending time migrating data you won’t use.
• Accounts Payable. If you do some analysis of how long you take to pay vendors or if you have vendors that are often late sending you invoices. If they are late you might have cut over to the new system and a purchase order or receipt that you want to match to the invoice might not be available. If this is only a small number then you might create an exception process rather than spend time to try to migrate data of receipted purchase orders.
• Purchase orders. Do you have long lead time purchase orders? If there a need to look at price history for a long time. Consider doing an extra of purchase, items, prices as this will likely give you some history for analysis and avoid migrating all old purchase orders into the new system.
• Product history. If you manufacture products is there information you need to keep for product tractability or warranty claims. Do some analysis of the typical life span of your products and work out if there is a window of how much data you need to have accessible. Dynamics AX doesn’t have a core warranty module but partners and customers have extended AX to include these features so consider what you need to migrate or extract into a data warehouse for analysis.
• Inventory and warehouse. You will take on inventory balances into the new systems. It’s un-likely you need a history of inventory movements in details. There are times when for example you ship by sea, travel is long so stock could be on the water in the time you convert over to the new system. If there is a shipping discrepancy the inventory and warehouse team might need to do some analysis. If you do this type of analysis this might mean you need to keep the legacy system up and running for the next 60-90 days and let a limited number of users access it.
• Projects. Some services or internal projects could go for a long time. Likely you want to bill and close out project in the legacy system and bring on WIP balances. But this might mean you have history in the project you want to do analysis over the life time of the project so you might need to consider which project you want to keep some data for.
• Expenses. Likely will want to pay and clean up credit card statements before you convert to the new system. If you do expense analysis you might want to extra a summary of previous expense to compare history in the future. To avoid importing them into the new system keep them in a data warehouse and use tools PowerBI to do analysis of the old data and the new data you accumulate in the new system.

Regulations

You will have to do some analysis in the country that you operate in to work out what you need to keep for tax purposes. One option is to keep the whole system if you can. For example use a virtual machine. By using a virtual machine you can move a full operating environment into something that would turned off and started in the future if you need to access the data.

For example if you just keep the database then you also have to keep the database software to be able to access the DB. Then the database software has to run on an operating system that the DB software supports. If you don’t maintain all this software then you aren’t going to be able to get into the data even if you keep it. This strategy will work if you are running a legacy system running on Windows or Unix/Linux but if you are running something exotic like a mainframe system that is dependent on some special hardware then you might need to do some investigation on options.

A virtual machine is a good option because you can also install the legacy application instead of just keeping the DB and have access to the tools in that application. If you keep the legacy system also keep the documentation and keep it archived electronically on the VM as well because you are likely to have to train someone in the future if you need to access the application.

Remember security if you build a VM. If the application and database has logins then you need to keep a list of those logins.

The main thing to keep in mind is do as much analysis as you can to avoid trying to migrate old data into the new system as you are going to spend a long time extracting, transforming, mapping and importing into the new system. If you are not going to use the data it will be a waste of time for the implementation team.

Cheers

Lachlan