Share what you know with millions of people
Focus is the best place to turn what you know into remarkable content
0
Can we lose critical data in an ERP migration?
My company is going to implement a new ERP system sometime in the next 6 months. We are prepared for the transition, but we want to make sure that the migration goes smooth and that all the kinks have been worked out. One question that keeps coming up though is can we lose critical data in the migration process? We are going to be transferring "historical" data and we want to double check that disaster recovery won't be apart of our migration, so is the migration process 100% secure with a trained ERP consultant on site?
Events
- Dos and Don'ts of Small Business Marketing May 29 @ 11 am PT
- Lead Nurturing 202: The Next Generation May 31 @ 11 am PT
- The Tricks to Paid Media June 6 @ 11 am PT
- Display Advertising for Brand Awareness June 20 @ 11 am PT
Related Activity
5 Answers
The question is not "can we lose data" the question really is "what data can we not afford to lose?". Yes you can lose data. You can lose data if it does not map properly to your new database. For example, you pay your salesmen commissions that are split up to 5 ways. The new ERP system does not have split commisions or it doesn't have the ability to split 5 ways. Or your historical data is rolled up by state but the new system splits it out by county, where does the lump sum go?
You can lose data if you don't thoroughly test the conversion process. Part of the conversion effort certainly should be a test conversion and don't just test the data from your top 3 customers or vendors. Make sure you include the ones you only do business with once every 2 years. Those are typically the ones that will cause data conversion woes.
Make sure that if the test works well, it will scale. You tested converting 100 mb of historical data but you have 100 Gb. Do you have enough horsepower? enough time? Has the consultant sucesfully converted this much data before?
In you data conversion plan, what is your fall back for day of conversion? in other words, you start converting and something unforseen happens and you cannot convert, or you convert and even though the test conversion worked, the conversion for real fails. Having a plan in place to handle the 'worst thing that could happen' will allow you to recover and try again 'next week'.
Just a couple of things to keep in mind.
You must make a complete inventory of your data. then you need to review the data with the people that consume it; Customer service;warehouse;accounting; executives and the reports they require daily weekly, monthly,on demand etc After that you need to rank and rate the data so you spend your money and time on the stuff that really matters.After that you need to have a specific plan on how the data will be replicated or replaced or surpassed in the new system. Make sure the users get a look at the new stuff well before go-live.
Maybe you can get away with a less thorough approach but remember the time to understand your critical data needs is before you start shopping for a new ERP system not after go-live on a new ERP system.
Finally test restoring all backups and make sure there are at least 2 copies with one of them residing off site.
Great question, but one I'm sorry you have to ask.
I could write a book on this subject, but to be concise:
1. DEMAND a full test conversion several weeks before the live conversion.
2. Don't assume that converting part of the data is representative of all the data. It most certainly is not.
3. You CAN lose data if it's not mapped properly to the new data dictionary (i.e. dates, codes, etc.)
4. Make backups... don't use (only) tape.
5. Bad data might be sitting dormant in your old system not really hurting anything, but a sequential read of the data for conversion might hit a snag, inhibiting anything to be read beyond that point.
6. Converting Master File data such as names, addresses, and phone numbers is relatively simple; converting transaction data, like invoices, check records, and history is significantly more complex. It might be a good idea to simply keep that data online in the old system.
Here's an old story that I was told is true... and it sort of relates: A chemical company was converting to a new EDI system. They were accustomed to ordering "barrels" of chemicals. They abbreviated barrels as "BA."
Well, in the new system, they ordered a BA of a certain chemical and waited for it to arrive from overseas. One day they got a call from the New York Ports Authority asking who was going to take delivery of a BARGE (BA) of this chemical. Ouch.
Data is an almost priceless resource. Please be careful with it.
Kirk Alexander
http://www.ceoteams.com
Stephen,
You mentioned that you are bringing historical data over - every single project I have ever worked on (30+) wanted to bring historical data over at the beginning of the project, but none ultimately decided to. There are a number of reasons - the old system didnt capture data as specifically as the new system will, transaction triggers limit what can be easily programmatically loaded, the cost to migrate old data is ultimately too expensive. Even in industries that are highly regulated and require data retention, we have embedded legacy tables and populated with static data. The fidelity loss could be the ability to drill down to, say for example, the OP30 labor and material issue tickets. This is a normal limitation of transactional systems.
Before I get flamed, YES, historical data CAN IN THEORY be migrated, but MOST companies agree that the cost and effort does not produce a valuable benefit when historical data can be accessed other ways.
Feel free to reach out to me if you have any other questions.
Scott Priestley
http://www.lionsharesoftware.com
scott@lionsharesoftware.com
What ever you do as discussed before besure that before the go-live you do the sesting of the Manster Data and make the desision to go live Yes or NO.
All Manster Data should be in a excel sheet so it can't get lost.Also frees the old system and keep the back-up. Besure you have enough resources for the testting. Hoop it heps to understand the migration
Answer This Question