Data Migration System Retirement: 25 Decommissioning Best-Practices

One of the main reasons we migrate data is to generate significant cost savings from decommissioning the old legacy environment.

Moving to a leaner, more modern technology and software platform can often reduce annual maintenance, staffing levels, license costs, support fees and development costs, often by a considerable margin.

Data migration is obviously a key enabling discipline in this regard as you cannot obtain the gains until you’ve correctly moved that legacy data.

However, for many data migration projects, the fate of system retirement falls into the following categories:

• It’s never achieved

• It’s delivered too quickly

• It’s delivered too slowly

I’ve worked on a number of projects where the business lacked the confidence to switch off the legacy systems so they lingered on, consuming power, resources and maintenance effort. The net result is a project that doesn’t really deliver on its benefits to the business. Not a good situation for your career or the organisation.

On the flip side I’ve seen systems shut down far too quickly. The switch is flicked to off and two months later the phone rings hot with those downstream data customers screaming at the loss of their bi-annual data feed (that you never realised existed) which is now gone forever.

Perhaps the most common scenario is where the legacy world is shutdown but only after a number of aborted attempts, acrimonious power struggles, endless discussions with stakeholders and confused business users.

Hopefully the following techniques should give you some pointers to include in your data migration strategy that will prevent any of these situations occurring.

I am indebted to other data migration professionals who also added their tips and techniques below.

1. Begin planning for system retirement on day 1 of your project, don’t delay until the end of the project as it will be far too late to prevent resistance in the business and technical communities

2. Don’t start your data migration with a mapping table or even data discovery, start it with a system retirement policy, use that to drive the design of your migration – John Morris

3. Each system may have a combination of business and technical owners, find them, record their details, document their agendas – are they pro or anti-migration etc.

4. Create an organisational chart surrounding these system owners, find their seniors, they may need to be contacted if power struggles emerge

5. The business and technical stakeholders own the retirement process, explain their role to them and how you will support them, get buy-in early

6. Ask what are all the reasons why the legacy application CANNOT be closed down, handle objections like a salesman, leave no-one in any doubt this is really going to happen – John Morris

7. Create a definitive break-down of activities for decommissioning, agree who will do what, when, how and why – get it signed off

8. Get your stakeholders used to small sign-off’s right from the outset, it will be a lot easier than asking for one big sign-off at shutdown – John Morris

9. Write down a basic communications plan detailing how you aim to communicate with each stakeholder, set reminders for when each communication is required

10. Get a senior figure onside to communicate the benefits of the migration to other sponsors and workers but don’t go around waving a big stick, explain the benefits at a personal, not just corporate level

11. Make sure they understand AND agree with what you’re trying to achieve, if they don’t understand it they can’t communicate it effectively, if they privately don’t agree you need to get them onside

12. Align your retirement plans with the training plans, don’t forget to factor on the training lag, it can take 12 months to train a workforce of a few thousand by which point the first trainees will have forgotten everything – John Morris

13. The issue of training can mean that your only option is a phased or progressive migration, think carefully about your migration strategy, big-bang isn’t necessarily the most suitable option – John Morris

14. Allow plenty of time for user acceptance testing (UAT) and generally creating trust in the new system – John Morris

15. There is a tendency for the business to hang on to the old environment “just in case” they hit problems, pre-empt this by delivering the migration in shorter iterations and getting UAT delivered far earlier in the process, at each cycle

16. The earlier UAT takes place the earlier you will find those hidden functions that the legacy environment enabled but have so far remained undocumented

17. Develop an archiving strategy early in the project to deal with any data that is not being migrated but is still required for regulatory or reporting reasons, don’t simply migrate data because “it’s there”

18. Trace system feeds and enter into dialogue with downstream data “customers” about what the retirement and migration will mean to them, get them into your communications plan

19. Don’t forget upstream, incoming feeds – are they aware of the new target platform – has that been factored into the design? It may not be your area but it can still prevent shutdown so plan for it

20. Use database and user access logs to monitor user or application activity, create a matrix of data against applications/usergroups, track the stakeholders down and communicate the retirement and migration plan

21. Create an out-of-scope document detailing all the data that is not in scope for the data migration and will effectively be lost, get it signed-off and distributed

22. Create a document that gathers all the conditions that must be met for system shutdown, distribute it and record the objections – determine the ones you need to act on and the ones which are political

23. Ensure you have a senior figure with sufficient authority to shutdown the legacy environment and give plenty of notice of the date and time this will happen

24. Put the business and technical teams on alert before, during and after shutdown to ensure that key indicators are monitored eg. rise in customer complaints etc.

25. Ensure that any data residing on the legacy systems is archived to tape, wiped and all licenses and support agreements are terminated

Dylan Jones

Co-Founder/Contributor - Data Migration Pro
Principal/Coach - myDataBrand

Dylan is the former editor and co-founder of Data Migration Pro. A former Data Migration Consultant, he has 20+ years experience of helping organisations deliver complex data migration, data quality and other data-driven initiatives.

He is now the founder and principal at myDataBrand, a specialist coaching, training and advisory firm that helps specialist data management consultancies and software vendors attract more clients.