How do you know when to kill your migration plan?

Migrations are for the most part painful, tedious, and time consuming. The aforementioned reasons to the left are why nobody likes to do them. But migrations are necessary, be it because of the software enhancements or hardware replacements. Generally, IT Departments have to “sell” migrations to business owners because they’ve made their money not spending it but saving it meticulously. However, they don’t understand that you’re seeing signs of their 5 year old server starting to die and THAT will cost them more.

The most important aspect of migrations becomes communication and to extend beyond that, the communication of expectations. Because if you don’t establish any or incorrect ones, as the service provider, you’ve now effectively under delivered, regardless of what you did. And what’s worse, that under-delivery may cost you a client. The biggest mistake people make during a migration is based around timing. In order to win a bid you claim to be able to do it faster, which you may be able to do, but at that point you’ve likely cut your error window.

By personal policy, I always err on the side of caution; I make sure my migrations take as long as needed to be as smooth as possible. And even then, they’re never smooth. You can come up with the world’s longest checklist and something unexpected will happen. But that in itself is the reason to still come up with that long list, because it’ll still limit the unexpected events.

Now that we have covered the aspect of planning for the unexpected, how do you handle the unexpected when it does happen? The first thing you do is a best effort quantification of its effect of your timelines. Regardless of the outcome of that you let your customers know what happened, what you’re doing, and most importantly what it means to them/their data/their email and how it affects their timeline if any.

The hardest decision to make during a project is when to cancel and regroup. This is tough because of two aspects, you’ll be doubling your work cost and primarily because it’s not really your call as much as you’d like it to be. Our rule of thumb is, if the alternate is NOT guaranteed to be successful we don’t do it. If it causes an outage during primetime for that company, we won’t do it. But ultimately, you must involve the business owner if think you’re going to cut it close and come up with a plan. Luckily on our platform, we have business continuity embedded into all of email solutions so any migration involving our email service will always come with a built in plan B.

Carlos Lascano