You have a Directory or E-Mail migrations to do? Who should you trust as your vendor? Coherence has been doing full time e-mail and directory migrations since 2004. That pretty much all we do. And we do it quite well. We have done very small migrations (only 5 accounts), very large migrations (over 1 million), and pretty much every number in between. We have done global projects and regional ones. We have been the single engineer on a job guiding a team of twenty through a migration, and we have led and/or performed in migrations that were outsourced to us of large teams of our people as well. In the end, though, it isn’t all the migrations we have repeatedly, successfully, done, it is all about how we got them started.
Every migration is different, and the challenges you will face in your migration will be different as well. What we do is find the best ways to solve those challenges. The challenges are not just technical, there are also timeline issues, political issues, and contractual issues that must be considered. We ferret them out, and then design the best solution to maneuver the project to keep it going great. It is what we do, and we do it better than anyone else.
A good example is at a customer where I was leading a team of migration engineers on a 200+ domain consolidating involving over 300,000 users and workstations. We came across a situation where the customer could not get the trust established to the source domain. When I got involved it took me only a small amount of time to find out the “why”. In this case the source FQDN of the domain was along the lines of territory.region.company.com. Most of the source domains are in that format. The domain builder had made their short name the same as the “region”, when typically the short name was going to be something based on the territory. The problem was that “region” was already the short name of a regional Active Directory Domain, which was already part of an on-going migration. We went to work to find out what we could do to get around this problem.
What we came up with were two potential low impact options. The first thought was to use an intermediate domain and migrate everyone twice. That would be a lot of pain and aggravation. Then, after thinking a bit more out of the box, came the ideas to move the servers only to an intermediate domain we could trust, and then do a trustless migration of the users and workstation. It was some pain, but given it wasn’t a full two-step migration for everyone, it was an option worth considering. We then refined it further – if the application on that server was not AD Authenticating, we could leave it in the un-trusted source. Now only a subset of servers would need to be migrated. Now we were getting somewhere. However, my rule of thumb when dealing with a complicated problem is always to think of all the answers before you pick a path – thinking doesn’t take much time, where a wrong choice just might.
That is when we investigated what was in that “regional” domain – it is primarily for servers, and those servers, as it turns out, were not AD Authenticating for their applications. Thus we came to our best (technical) option we which was to drop the trust to regional domain and establish the trust to the duplicated named territory domain.
The Migration, at that point, could continue moving forward. Where once it was going to have to be delayed, they could now move forward with the two plans we presented. Since there were politics involved, the customer wasn’t ready to make that decision at that time. However, given that we had two routes, we could move through the early stages of the migration knowing we had at least one path that would be both acceptable and would work. If we had to switch from a trusted migration to a non-trusted migration, the change was to pre-migrate a small number of servers into one of the domains that was already trusted and then keep moving. In this case that add a week or two, at most, to the project schedule.
This is just a recent example of how our team comes up with creative solutions to find the best and most cost-effective path forward for our customers.
What else is in our toolkit? We have used (and in many cases re-used) custom coding solutions in a variety of languages to augment and automate the migration process. We have combined utilities that may not normally be used together to create an automated and seamless migration process. We work with whoever is engaged in a project – often times there are multiple vendors participating, and we work hard to make sure we all work together effectively for the customer. We always provide good perspective on ways around problems a customer might be having regardless if it is really part of the “migration” or not. Most of all we bring years of experience in migrations to the table.
How many combined hours? Our small team has, as of the writing of this article, just over 100 years of combined experience of being completely migration focused. That works out to be an average of 8.5 years of experience per person on the team. To put that in another perspective, that means we have around a combined active working on migrations set of hours of 180,000 – yes One Hundred and Eighty Thousand hours actively working on Directory and E-mail migrations. It is said that you need around 10,000 hours to truly consider yourself an expert, I think we are well past that mark.
Who do you trust to do your migration? I recommend you go with people who have “expert” status and then some. I recommend you trust a company that only does directory and e-mail migrations and has the most dedicated years of migration experience per team member than anyone else out there. It is all we do, so we are going to do your migration like our company existence depends on your migration success… because it does.
Michael Gastright is a Principal Architect, CEO and President of Coherence Inc
The Coherence team has experience doing migrations from Active Directory, Lotus Notes, NDS (Netware), GroupWise, Exchange, G-Mail, Office 365 and more than a few POP and IMAP based mail systems. They use predominantly the Quest migration tools, though they have done more than our fair share of migrations using others including native tools.
