Managing Moving Migrations: Hey Tech Bro Where’s My Document?

TL;CR You have to have a consistent set of names, and those names have to be agreed, recorded, and socialised or otherwise everyone’s going to get very confused.

Last time, Managing Moving Migrations: Generalised, I defined a non-specific system to use to discuss how to move data between two live systems.

• Source System, a legacy Content Management System
• Target System, a collection of cloud resources, a structured data store, an unstructured data store and a web application

This time I want to look at the first requirement

1. Users must know where their content is at all times

This immediately brings us to the second of the Two Hard Things in Computer Science: naming things.

Its simple though you say we’ll just call them the ‘old’ and ‘new’ system, and as its almost Christmas, short blog post, see you all next week.

This would work but what if the system you are moving from is already known as the ‘new’ system, at least by some of the old hands. This really happened to us. There was a serious suggestion that it should be called the ‘newer’ system.

Fine we’ll use ‘source’ and ‘target’ which sounds more computery and we haven’t used those before. Also source and target have the same number of letters which will make any scripts we write line up nicely.

This makes a basic assumption about migrations that they are one to one. Doing this for numerous clients has shown this is rarely the case, its often one source to many targets or many sources to one target or in one memorable case many sources to many targets.

However even when it is one to one its really not. That’s because, at a minimum, we’ll need somewhere to test the process. In reality we find the following systems, all of which need names.

• Source Production System(s)
• Source Test System(s)
• Target Production Systems(s)
• Target Test System(s)

Hold on, it is almost Christmas, who cares call them Austin, Brontë, Chesterton, and Dickens and cut a long story short. I mean what’s in a name?

See my earlier post Script === Shotgun: You may want to reconsider giving users automation capabilities this is going to be an automated process but without clear names things happen and the consequences are bad, see the following couple of examples:

• “There’s a problem with the target system it’s lost data”, this took thirty minutes to diagnose that the issue was the person reporting it meant the test target system whilst the techie was diagnosing based on production target logs.
• “Bum I think I just ran the production data into test”, this has all sorts of bad implications because you now have data in a system that may not have suitable governance on it, for example you are holding personal data of a real customer in a test system.
• “Double bum I think I just ran test data into production”, what is someone acts on this? For example your delivery company takes it as a real order and suddenly 100 Pimms Jugs are being packaged and sent to a developer’s house, or someone takes a financial decision for the company. Also deleting data from production has all sorts of governance implications and is frequently harder than you think.

So everyone involved, users, managers, techies, and governors has to know exactly which system they mean and it has to be unambiguous and obvious.

I like the three assets (PST) naming strategy as it becomes very obvious when one of those is missing and I use the following order so the critical information is first.

Purpose

What is the purpose of the system you are talking about?

1. Production, holds real data that must be under full governance at all times.
2. Test, holds test data only used by the business to check things are working
3. Development, a system used by the techies to verify some aspect is working

Stop

Which part of the journey is this?

1. Source, where the data originates
2. Transfer, where the data resides when its not ‘in’ either system
3. Target, where the data will end up

Type

What type of system is it.

This will vary based on how many source and target systems you have but I recommend naming them for what they are so examples might be:

1. SharePoint 2016 On-Prem
2. SharePoint Online
3. Azure SQL Service
4. Azure SQL Managed Instance
5. Azure CosmosDb
6. Azure Storage Account

Now you have the three attributes you can easily spot when something isn’t fully defined, for example:

Can you check the Target Azure SQL Service

For Production or Test?

Can you copy the data into the Production Target

Which of the target systems in production do you mean?

Its not enough though for you to know this everyone must, so it needs to be written down.

You MUST have a single project repository that holds critical information accessible to everyone on the project, and everyone must know where it is.

We normally use the client’s document management system and have a single README.md document that contains all of the critical information including what we call the systems.

TL;CR You have to have a consistent set of names, and those names have to be agreed, recorded, and socialised or otherwise everyone’s going to get very confused.