New System Implementation Planning
Some things that you can do to prevent complications related to new software systems implementation.
1. Verify existing hardware, operating system, and software infrastructure meets or exceeds the minimum requirements for the new software well ahead of time. Update to meet prerequisite beforehand.
2. Read all of the documentation related to the entire data migration process and software implementation process in advance. This allows you to be apprised of any issues that might adversely affect your staff.
3. Plan to have a thorough test migration done well in advance of the intended go-live date.
4. Get proper training on the new software in advance of doing either a test migration or a live migration. Enough time should be allowed between a test data migration and the final go-live date to do testing. Proper testing of both the software and data is critical prior to the final live data migration to get more familiar with the software and proof the software configuration and the integrity of the data migration.
** Testing should include end-users’ replication of normal work processed over several days of live data that was done in their old system. Limited generic test data may not reveal the subtler issues that will be encountered in actual use.
Data migrations can go awry for several reasons, most often these bad situation scenarios can be avoided.
Some examples include …
- Data Migrations where excessive corrupt historical data is present.
The MIS person for a longtime Counterpoint version 7.5 user did an in-house test migration to the newer NCR Counterpoint software.
This particular company has a long-term policy to never purging history of any kind. At the time of their test, the company MIS person indicated it took him over a month of clean-up work before the migrated data could be considered usable. Further, he indicated that a lot of the corrupt data was related in older history records (and this was especially so with transaction dates). The company had detailed transaction history going back over 30 years. Typically, most retailers only keep around
2 years’ worth of sales history. Unless one has warranty related issues 30+ years of historical data may be excessive.
The migration plan was to start the live upgrade on a future Friday night and be live by the following Monday morning. This approximately 48+ hour time frame would be considered very aggressive even under the best of circumstances. The company required over a month just editing out corruption data from their test conversion. Other issues may arise that make 48 hours to go live difficult to achieve! A less aggressive plan would be a better approach.
- Trying to use the new software on older hardware and unsupported older operating systems.
This approach can be a recipe for disaster resulting in migration failure with damage to your data.
In one recent example, a business owner copied his current updated software installation onto a really old server that was running an obsolete, unsupported operating system.
The software was failing due to insufficient memory and system resources. Software/operating system conflicts were also corrupting data. When attempting to run file rebuild utilities, and detailed history reports, the performance of the software was made the software functionally unusable. File rebuild operations on the obsolete system took 6 hours instead of less than 4 minutes on the current systems to be used after migration. Reports required similarly took hours rather than minutes as they could have.
- Indefinite implementation postponement followed by the decision to go live without all of the appropriate parties being adequately coordinated.
A partially complete implementation project was on hold indefinitely. Months later the store was scheduled to go live on a specific date, but this was not communicated adequately to the rest of the migration team. The assumed prerequisite set-up and configuration work required had been not been performed beforehand. This massive amount of work could not be completed with the less than 12 hours prior notice considering it involved a complete redo/reconfiguration of the software and core data before it could be used in any form.
- Incorrect or incomplete data being provided to tech support people.
Data provided to CCS tech support is imported into a test system for review. If Incorrect or incomplete data is provided it cannot be reviewed and prepared for use properly. On the scheduled go-live date required data may not be found on the system or corrupt data may be missed in the preparation tasks.
Some critical food for thought!
– John