I’m functional – what that means is I understand the business process of the software I work with and how to make it work for each client.  Functional also means that I can take the ideas of the client and put it into a format that the technical people can use to build anything needed.  But the lines can become very blurred between the listening and cataloging vs. the coding and building.  Good technical and functional consultants will know plenty from both disciplines.

Conversion, is the process of transferring the existing client data into their new system.  The functional consultant will work with a legacy system technical person to find what can be extracted and manipulated to fit the new.  Also, it will be necessary to work with the end users to understand what the expectations are for any historical data placed in the new system.

Because we want our new systems to be as clean as possible, we typically ask for mistakes to be corrected, or data to be scrubbed.  This will always cause a problem with historical records because the original problem, and the correction will fall into the period being brought forward.  If there is any hope of reconciliation to the legacy system, we need to understand and catalog these issues.

Is there any way around it?  Not really.  There are three possible ways to deal with the problem:

1. Fix the issues in the legacy system prior to ‘conversion periods’.  The client will rarely like this, as it may cause restated financials, or a reduction in converted data.  This is the best and cleanest method for the new system.  The audit trail is very obvious in the legacy system, and the newer system does not need to contain values that are incorrect.

2. Fix the issue during conversion.  This is actually the easiest, because we can devise ways to transform data from one thing to another in between the systems.  This is also the messiest, because the audit trail virtually disappears between systems and that could create major headaches for the client.  If this method is used, make sure the client is very aware of the implications.  Your responsibility will include documenting the trail thoroughly, and being able to prove beyond any doubt, how the data is transformed.  If you can include old values into non-validated fields such as descriptions, etc., you may be able to create a traceable path.

3. Fix the issues in the new system.  Here is where most clients will land.  Their new system will most likely have capabilities that the old did not.  Your responsibility here will be to ensure they understand the new system enough to correct the issues.  You will also need to help them inactivate fields or individual data elements so that they can no longer make the same mistakes.

You have to know the technical side of your software so that you can understand how the data in the legacy software will affect your new system and make recommendations accordingly.