You’ve spent years creating Plans and accumulating data in your legacy DRP software. Now you’re no longer sure that old software is capable of providing everything you need. But you assume you face a ‘Hobson’s Choice’: stick with the old legacy software (ugh!), or start all over again (worse!). Your assumptions may be wrong. You can replace your old legacy software – without losing all the hard work and data accumulated in your earlier efforts!
As part of replacing that old legacy DRP software, you must consider what to do about your existing data:
- Can it be migrated into another, new BCM software product?
- Has it been done before?
- How will it be done? (How long will it take? What resources will it require?)
- What are the challenges to the migration effort?
- Will there be a loss or gain in value from the migration?
- What is your vision for the end-state of your existing data in the new tool?
Fact: there is no data migration Magic Wand. Don’t confuse “document migration” with data migration. Anyone can move your MSWord-based plans from one place to another. But moving your BIA results, teams, dependencies and other relational information will be as complex as the form and format where it sits presently.
Based on our experience migrating data from many legacy BCM software products, a typical data migration effort may take as long as 3 calendar months and involve daily touch points between the vendor and the customer’s BCM administrators. The data migration timeline and work effort will depend on what you have, how existing data is housed, and what your goals are.
Basic data migration involves a series of activities. I can’t vouch for how every BCM software supplier does it, but here’s how we do it at eBRP:
Analysis: Every migration effort is unique, and a project plan must be created to achieve the desired end-state. Our Business Analysts review the source data-stored and break it into data packets that can be imported into the new system. In many cases the legacy data may be broken into 30 or more components for import, such as – locations, departments, staff, vendors, processes, IT services, Technology sub-systems, supplies, resources, plans, tasks, teams, etc.
Extraction: Based on the Source Analysis, scripts are created to extract data into structured files that can be used to import the data components into the new tool.
Shaping: A ‘like-to-like’ migration, from the old system to a new system, is probably the easiest form to manage. But a critical question must be asked: what value is achieved by moving to a newer system if everything remains the same? Implementation of ‘data shaping’ during the migration process – changing the information architecture and applying updated business policies to old data – can result in more than simply maintaining the status quo. Data shaping is like melting down a gold bracelet and pouring it into a new ring mold – the relevant legacy data is extrapolated to fit the current state of the business.
Deployment: Based on the existing data structure of the target software, the data migration is broken into phases. Each data component, (locations, employees, Teams, Business Processes, plans, etc½) is imported one at a time. With the new ‘data shaping’ parser in place, the data is extracted from the old database into the new tool. The legacy data, now shaped with the current business policies, is represented in the new tool in its desired state. Why bother to break the database into components?
Validation: Each migrated data component must be validated and signed-off on before cycling back to migrate the next set of data. One error can be compounded when matched with successive data components. By assuring that the migration of each data component is valid, the chances of compounded errors are virtually eliminated. We don’t believe in ‘trial and error’ – we believe in trial and validation.
End state: Because the desired end-state is known from the beginning, the process of migrating the legacy BCM software data into the new tool, data shaping, validation & sign-off should result in matching expectations.
The migration from a legacy database must be an interactive effort. The key thought process is ‘what is the desired end-state’ of the migration? Thoroughly considered and well-planned, the migration can ensure that the prior years spent planning are not lost, while leveraging features of the current BCM software tool to create a viable & sustainable BCM program.
If your legacy BCM software is no longer meeting your needs, you aren’t stuck. All the planning efforts you’ve made can be migrated to a new, more effective tool. Just make sure any prospective new BCM software vendor is capable of data migration – not just document migration.
