A tale of migration and miscommunication

Before this last week, I considered myself reasonably competent and able when it came to handling myself in a professional manner. As the migration I've been working on wrapped up, I was sharply reminded that I have much to learn.

Planning and research can only take you so far - communication and experience are strong factors in successfully pulling off important (any) projects.

First of all, this is not a doom and gloom scenario, a lot went right. We're just going to focus on what went wrong as that's where the good lessons are.

1. Did not thoroughly check documentation of LOB software to ensure all the pieces were there to migrate it successfully.
2. Did not communicate with LOB developer/support (same person in this case) to ensure they would be available for emergency support during the migration.
3. When an issue did arise, used email as first line of communication.

So, let's deal with #1. The documentation was asked for when the software was written a year or so ago. When I initially went through it, I only noticed the client install, but figured the server part was at the bottom - it was just a database hosted on a SQL express instance running on the server, so wasn't much to it. Had I actually been looking for specific server-side installation instructions, I would have realized there was no guidance at all for that. That may have prompted me to try and set up a test instance in my lab - where I would have realized the problem.

Next up, #2. Assuming I'd done #1 properly, I would have contacted the developer right away, and not dropped a bombshell in his lap. To be fair, it was a pretty simple problem with an easy resolution, but an emergency none-the-less. By not contacting him prior to the migration I opened myself up for a potential show-stopper - what if he had been on vacation for three weeks? (I would have finagled the old server's SQL instance into life, but that's not the point)

Finally, I dropped the ball by again assuming he checked his email regularly (with an unhealthy dose of avoiding speaking to people). According to office staff, he did, so I went there first. My general instinct is to email first, as I've tended to get better response from technical people via email rather than phone. However, you can always get much more prompt attention when you're on the phone being a hassle. He responded right away on the following Tuesday morning when one of the office folks called him. We're still not sure why he did not respond to emails, but either way - email should never be the first line of offence when trying to resolve emergency situations.

Lessons learned:

1. Take time to run through each step of the migration. Do not assume documentation will give you all the answers. For mission-critical applications, KNOW that they will work, don't guess so.
2. Notify any parties with a stake in the operation about the event in question. Not via email, but by calling them so they KNOW something is happening.
3. In an emergency situation (should one arise) - USE THE PHONE. Email should only be used in emergency situations to send helpful information, not convey the initial problem.

There is a final lesson in all this. When estimating your time for anything with 'migration' in the title, double your estimate. If it involves tools you've never used before, quadruple it to cover learning time. Even if you end up far below your estimate, your client will appreciate it. Further, do not attempt to rush a migration - you will end up sorry you tried to beat the clock for convenience sake. Always wiser to just back away until you have enough time.

Hope this helps someone avoid my mistakes.



If you're curious how the rest went, I'll be doing another post on the merits of migration helper kits.