Time vs. Effort in Data Center Migration / Relocation
I find it interesting that when you’re looking at time vs. effort in migration and relocation projects it’s not even close to the same. Based on our experience, I thought I’d represent the data in a visual way to show what it looks like from our methodology and how we implement migrations. Now keep in mind, the time and effort levels we are talking about here are in percentages. So the larger more complex and intricate the project is, the longer it will take. However the percentages should still be accurate.
Now defining the difference between time and effort can be summarized as such… Time is the duration in which it takes to complete your project, effort can be considered man hours across the entire project. So we will be dealing in Percentages of both Time and Effort. 100% of time might be 1 yr. 100% of effort might be 3 man years. If level of effort to complete a 1 yr project is 10% that doesn’t necessarily mean it will be completed in 1.2 months.
In understanding Time and Effort, we need to look at the activities that are identified during the completion of a Migration / Relocation. The first thing is to look at what is the process that you go through in the migration life cycle. Yes it is a life cycle. Depending on the number of systems that are impacted with the migration, you should have a repeatable process to implement for each system set. (note, some folks consider systems to be an application. I consider a system to be any number of applications that share the same infrastructure diagram). In the planning efforts that we manage and work with there are four distinct activities. These activities make up our methodology called A.A.I.M., Assess Architect Implement and Migrate.
A) If I were to think of an acronym of what really happens it would be SPBM, Strategy, Planning, Building, Moving… Not a good Acronym so we’ll stick with AAIM. :-) Project planning is perceived as happenning in the assessment phase but that really is is a strategy phase. We come out of this with an understanding of what you’re end goal is, as well as an overall larger view of how you can get there (i.e. PMO structure and roadmap, Server Inventory, System to Server dependency matrix, start of capacity planning).
A) So following that is the architect phase. In the architects phases when you’re actually planning your architecture. You will define what the environment will look like. Once you know what the environment looks like you can plan for your systems to Move, or be created within that new environment. There are specific deliverables that come out of the Architecture phase (planning) such as your existing environment diagrams as well as future state diagrams for your systems as well as your network infrastructure and all the different things that make up your compute environment. So really architecture is an aspect of planning and creating deliverables associated with the planning phase. We should have a migration schedule wrapped around system planning groups at the end of this phase.
I) Next we have implement : This is the building of the environments and sub environments associated with all of the architecture diagrams. Now depending upon the processes that are in place this will entail everything from procurement to installation of base server software as well as application specific installations. At the end of this phase the applications and or system should be able to start testing.
M) And finally we have migration. This will be the implementation of the migration activities as defined in the detail planning the occurred previously. This is usually the shortest time frame within the migration project however remember that doesn’t necessarily mean it’s not a larger effort. Size and scope of the migration will determine how much effort is involved.
So to wrap things up, If you are planning any sort of migration, remember to budget for sufficient planning time in order to implement with little to no disruptions. As many different folks have said: Plan twice, move once… Or was it measure twice, cut once….. Or… you get the picture… I hope.
Until Next time: