Top migration worries: Estimating cost and duration

There’s an old adage that says, “if you have enough time and money, and no market pressure, you can migrate anything.” Unfortunately, I’ve never met a client that fit that criteria. It’s understandable then, that once the technical concerns about migration have been put to rest, the next logical question most ask is simply, “how much does it cost, and how long will it take?”

Many migrations are planned events with established budgets and anticipated go-live dates. However, constantly changing business environments often necessitate unexpected migrations. These can be driven by an acquisition, divestiture, a supplier who encounters a serious technical issue, a company that goes out of business and many other situations.

Whether the migration is planned or unplanned, organizations are always concerned about:

• Lost productivity
• Major disruptions to the business
• Selecting the best time to make the change
• Staying on budget

There are many variables that go into calculating the cost and duration of a migration. The basic assessment process that can help minimize technical risk will also help us identify those variables. Highlighted below are four key questions that can help you determine the cost and duration of a migration project.

What’s the scope of work?

Are we migrating databases, ISV applications, custom code or all of the above? Understanding what has to be moved is the first step. Once we know the project scope, we can start to approximate how long the migration will take…but there are other inputs to consider before the final cost and duration can be determined.

What are the testing requirements?

In one of my earlier blog posts, I said that testing is critical, for obvious reasons. If you don’t have a solid test plan, it’s unlikely you will have a successful migration.

Testing is often one of the largest cost components of a migration and can be as much as 70 percent of the project. The longer you test, the longer the duration, hence the greater the cost. Testing is usually the client’s responsibility, and during an assessment, we in IBM Systems Lab Services Migration Factory work to ensure that each client’s plan is appropriate for the workloads being migrated and help minimize any unnecessary cost during this phase.

When can the migration start, and when does it need to finish?

Once we have an initial estimate of how long a migration is likely to take, including testing, we work with the business units to see when the migration can be done. For most organizations, there are many blackout periods when systems cannot be touched. Planned migrations usually take this into consideration but unplanned ones may not have had time to consider it.

How the migration is done will also affect duration. Will this be a “big bang” migration where all systems go live on the same weekend, or a phased migration where systems go live on the new target in waves?

Who will do the work?

There are many ways to build a migration team that can help minimize the cost of the project. As you are planning, consider the differences in the cost of working with IBM, your own staff, business partners and system integrators.

Potholes along the way

There are a number of things that can cause the cost and duration of a project to go astray. Scope creep and the inability to stay on schedule are at the top of the list. There are legitimate reasons to expand a migration project, but unplanned or unnecessary scope creep can have a negative impact on cost and duration. The inability to stay on schedule is a bit more difficult to manage. Inevitably, challenges can arise during a migration that set the project back. The best thing you can do is to handle them as they come and adapt your plan if necessary.

The other cost question…the cost of NOT doing the migration

Companies typically spend a lot of time trying to understand the cost to do a migration and often find reasons to put off making a change. But how often do they consider the cost and risk to the business of NOT doing the work?

• What are the costs and risks of waiting?
• Will it be more expensive later?
• What do unplanned outages cost for every hour the systems are down?
• What is the risk of running on old technology, in an unsupported mode, hoping nothing breaks?

These are just a few of the many questions to consider when you’re evaluating the cost and duration of migration projects.

In my next post, I’ll cover the migration worries clients have regarding the skills, culture and operational efficiency of their company. Meanwhile, if you’re looking for help with your migration project, contact IBM Systems Lab Services.