The art of moving computer users from one computer program or system is called migration. One example of a migration, which we will discuss in this series, is Migration To Blogger Beta.
The simplest migration - when all principals (involved computers, software, and users) are identical - we call a homogenous migration. With all principals being equal, planning a homogenous migration is simple. Take the number of principals, divide by the number of days, weeks, or months allowed for the migration, and you get a count of how many principals must be migrated per day, week, month.
That's the simplest homogenous migration, and that works fine if there are no problems.
To allow for problems, you plan to work harder during the part of the migration when there are no problems being experienced. You migrate a few principals in the beginning, carefully. You work really hard in the middle, maybe twice as hard as you need to. And you hope for no problems, so you can coast at the end. That way, as problems are discovered, you have that period at the end to catch up.
That's called a phased migration.
The nice thing about a homogenous migration is that all principals, being equal, are interchangable. If one or two principals (people, in this case) are on vacation, that's fine - you can migrate them at the end. If a group of principals need to be migrated together, no problem - you schedule them together. If a holiday comes up during the migration, fine - you work a little harder before and after the holiday.
Very few (OK, none, really) migrations are ever totally homogenous. Just as (in my theory) no two computers in the world are 100% identical, neither are people. You cannot blindly migrate an entire population without allowing for variances. Not unless you enjoy dealing with problems, while having fingers pointed in your face constantly. And it's a good idea to have an up to date CV too.
So you get real, and plan a heterogenous migration. I'll discuss a heterogenous migration in the next post in this series.
The simplest migration - when all principals (involved computers, software, and users) are identical - we call a homogenous migration. With all principals being equal, planning a homogenous migration is simple. Take the number of principals, divide by the number of days, weeks, or months allowed for the migration, and you get a count of how many principals must be migrated per day, week, month.
That's the simplest homogenous migration, and that works fine if there are no problems.
To allow for problems, you plan to work harder during the part of the migration when there are no problems being experienced. You migrate a few principals in the beginning, carefully. You work really hard in the middle, maybe twice as hard as you need to. And you hope for no problems, so you can coast at the end. That way, as problems are discovered, you have that period at the end to catch up.
That's called a phased migration.
- Pilot.
- Main.
- Followup.
The nice thing about a homogenous migration is that all principals, being equal, are interchangable. If one or two principals (people, in this case) are on vacation, that's fine - you can migrate them at the end. If a group of principals need to be migrated together, no problem - you schedule them together. If a holiday comes up during the migration, fine - you work a little harder before and after the holiday.
Very few (OK, none, really) migrations are ever totally homogenous. Just as (in my theory) no two computers in the world are 100% identical, neither are people. You cannot blindly migrate an entire population without allowing for variances. Not unless you enjoy dealing with problems, while having fingers pointed in your face constantly. And it's a good idea to have an up to date CV too.
So you get real, and plan a heterogenous migration. I'll discuss a heterogenous migration in the next post in this series.
Comments