Managing Moving Migrations: Generalised
TL;DR This series is about how to do this generically but we’ll use an example inspired by a real life moving migration.
Last fortnight I talked about Managing Moving Migrations: Who cares? to identify the stakeholders and also generate a set of requirements when moving data between two live systems.
This week I want to define a very generic pair of systems that will allow us to investigate each of the requirements in depth. I’m going to avoid using actual systems as it would be too easy to get bogged down in technicalities instead we’ll have two types of system. I’m using a real life migration to inform this so its not entirely made up for convenience.
Source System (CMS)
The source systems is a Content Management System (CMS) the inspiration was a SharePoint On Premise system but it could equally have been WordPress, Drupal, django, Cold Fusion.
It stores structured data, think lists or tables, and unstructured data, think documents, internally and provides an API that allows them to be manipulated.
The client is using this to manage a business requirement that is remotely accessible but the data volumes over the years have exceeded what the system is comfortable using and its getting harder and harder to find people who know how to manage such a system.
Target System (Database + Storage)
The target system is a set of cloud based resources that will provide the same functionality.
The structured data will be stored in a database, the inspiration here is Azure SQL Server.
The unstructured data will be stored on file storage, which could be an Azure Storage Container.
The application has already been provided as an Azure Web Application.
The client wants to move to this because they are moving away from their data centre to cloud based systems and the cost of porting and maintaining the servers in the cloud is prohibitive.
Requirements
So far we have the following requirements.
- Users must know where their content is at all times
- Users must not be able to access the same content in multiple locations
- If a user cannot access a piece of content, then the period it’s not accessible must be as short as possible
- Managers must have a management method that caters for a continuous evolving process with a stop condition rather than known date
- Managers need indicative timings from technology
- Managers need user engagement to be minimised to reduce the number of changes during the process
- Third parties that generate content must be catered for
- Developers need a representative, but not production clone, system to test the migration process on
- Developers need to be able to halt the process, in the case of unexpected data, resolve the issue and restart the process
- Governors need to be able to show that all content has been migrated in an acceptable manner
- Governors need to be able to show appropriate project metrics
Next we’ll look at the first of these.
TL;CR This series is about how to do this generically but we’ll use an example inspired by a real life moving migration.
