Image: iStock/klmax

Software is (somewhat) infinitely malleable. In fact, this is one way that companies get in trouble: They build something that isn’t particularly good (or bad), and figure with just a bit more effort it will wow customers. (Hint: It won’t.)

The same principle holds true when migrating systems, perhaps from an on-premises environment to a cloud environment, or perhaps migrating from one database system to another. There’s a great way to cut through subjective, wishful thinking in such projects, Gartner analyst Henry Cook has posited: Calculate the costs.

SEE: Power checklist: Local email server-to-cloud migration (TechRepublic Premium)

The wrong question to ask when migrating systems

This isn’t where most people tend to start. As Cook highlighted, many start by querying whether a system could be migrated. In so doing, “It causes the team to collectively share how confident they feel about proceeding, thus prompting a subjective assessment.” And, indeed, “It is always possible to migrate a database system,” or another system, according to Cook. Given enough time and money, migration to a new system is possible.

But no one has enough time and money to do everything necessary. This is why Cook is correct to suggest an alternative inquiry to uncover the feasibility of migrating a system:

What the organization really needs to know is what it will cost. By cost we mean how much time, effort, money and resources it will take. It is then possible for management to compare the estimate of costs to the amount of resources available and check that the project is feasible.

Why cost? Because “Estimating the cost focuses the team on areas of uncertainty. It reduces the emotion and subjectivity. The team will either know the scope of the migration or it won’t.” Of course, estimating the cost depends upon being able to gather the requisite code, data, etc. to fully estimate what will be required to move it. But a team incapable of gathering the right inputs is almost certain to fail to deliver against promised outputs.

In evaluating potential costs, it pays to inventory existing assets, both tangible and intangible. Intangible assets might include experience migrating similar systems in the past; an experienced team should be able to migrate systems more predictably and cost-effectively than an inexperienced team. One consideration: It can help to reduce costs to bring in a partner experienced in the type of migration you’re attempting.

SEE: Editorial calendar: IT policies, checklists, toolkits, and research for download (TechRepublic Premium)

On this note, it often makes sense to start with a smaller, less costly project. This enables a team to more easily estimate the costs as well as develop “migration muscles” that will help to bring down the cost of larger, more ambitious projects.

Regardless, focusing on the cost of migration, rather than the possibility of migration, can help to weed out subjectivity in the decision-making process. This, in turn, should help teams to be more successful with their systems migrations.

Disclosure: I work for AWS, but the views expressed herein are mine.