If you’re upgrading or replacing your domain, now is the perfect time to leave your .local behind.
If you’re on .local and weren’t planning on migrating off, here’s why you might want to.
Before we get into it, moving off a .local is really a choose-your-own-adventure scenario. There’s a lot of discovery that needs to happen on the front end, which will help you make better informed decisions. That is good, because there are a lot of different paths you can take and you want to make sure you choose the correct one for your environment. Choose wisely, because you have to live with it for a while or pay the price. There are so many different decisions you can make, and they all can impact each other.
Rome wasn’t built in a day and your domain migration won’t be either.
You’ll also want to decide if you’re migrating all or part of your existing domain, or doing a cutover. If you’re migrating, you’re taking what you already have and moving some or all of it over. If you want to cut over, you’ll end up rebuilding (and hopefully avoiding errors and mistakes from your previous environment). To determine if you will do a cutover or a migration depends on availability of both domains simultaneously and how long will it take to do it manually.
Step 1: Conduct an Analysis of Your Existing Domain
Before you even consider migrating your domain, you need to know:
- Your current Active Directory structure, including Group Policies, scripts, certificates, users, groups, and the OS of all the systems tied to your domain. You also need to know if you have encryption tied to your AD. If you do, you might need to disable it during the migration, depending on which program you’re using.
- What email system you are using and what email system you plan to use: local or cloud, and knowing how that will integrate into your AD structure. This is going to be the biggest impact on your options and what you decide at this juncture could impact whether or not you do a migration or a cutover and how you’re going to do it.
- If you’re on SharePoint and if it’s on premise or in the cloud. You’ll want to pay close attention to the permissions, because they’ll need to be changed to the new domain.
- Your antivirus: which one is it? How is it configured? Can it be migrated?
- Your database security. Do you have SQL servers or other database services? You’re going to have to reset those permissions as well and know all your master passwords. Document, document, document!
- All your file shares and share permissions. Do you know who can access what? You’ll need to recreate it (or maybe fix a security issue you didn’t know you had for a long time…). Do you have a plan for how you’re going to move your shared data? Are you moving the server(s), or creating a new environment from scratch? Where is it all going and how is it going to be accessed?
- Your printer shares and drivers – make sure you have the proper drivers and you’ve tested them. If the drivers aren’t configured properly and you don’t have them all, you could encounter some problems with users being unable to print.
- If the firmware of your multi-function printers or other devices support the new domain. If it isn’t compatible, look for firmware updates or contact your vendor. Find out if these devices are AD or email integrated, and if so, document what you will need to change.
- What line of business applications you’re using, if they’re capable of migrating, what the data backup and restore processes for them are, what the licensing is (physical or client access, etc). Decide if you’re going to have to redirect the end user shortcuts and if so, how.
- If your storage can keep up with migration needs and if there is enough space. You have to match your storage and its performance with the length of your downtime window and the possibility of running both environments simultaneously. I’ve seen it take days (or weeks) to move data, so don’t underestimate this. Some servers and some data will not migrate and you will have to build new and duplicate your data.
- How your phone system integrates with your domain. Is it AD/email integrated? If you’re not sure, check with your vendor.
Step 2: Decide a Migration Path
After you’ve done your full analysis of your environment, you may realize there are a lot of qualities in your environment you hate and don’t want to keep. Or you may have had some unidentifiable persistent AD issue that you could never quite squash. If so, you may want to opt for a clean cutover.
A cutover gives you the ability to build an all-new environment and do extensive testing before go-live. However, most organizations with on-premise Exchange have to opt for the migration route if they’re going to stay on-premise or hybrid. Another main reason most organizations go the migration route is because of their pre-existing structure that they do not want to change, and would be too cumbersome to rebuild in a cutover. For example: an extensive, nested Organizational Unit (OU) hierarchy with many GPOs applied.
It’s important to note that most Microsoft first-party programs have well-supported migration methodologies, so many organizations opt to migrate their Microsoft applications instead of rebuild.
Almost all organizations use some combination or mix of the two. They may migrate some servers that simply can’t be rebuilt, due to effort or IT knowledge, while building everything else from scratch. There are almost always a few servers that are ‘problem children’ that are difficult to do one solution or the other with. Another reason to do a combination is that it may be faster to migrate users and groups rather than to create them from scratch. With either process you can easily migrate the users’ computers while keeping their current desktop profile settings.
Step 3: Create a Project Plan
You’ll have to break down each element in your domain, and decide if it needs to get moved, and if so, how. This can all depend on if you decide to go cloud from on-premise, vice versa, etc. Plan the proper resources for this project. You might need additional bodies to run from workstation to workstation to test or leave behind documentation for the end users. Create a communication plan ahead of time and start educating the end users on what they can expect.
Do a test backup and restore before starting, because if anything goes south, you’ll need to know that your restore works and how long it would take you. So, if you make any kind of critical error during the migration, you know you can roll back to your old domain. Always have a backup plan to your backup plan!
Step 4: Happy Migration!
Like I’ve said, everything from here on out will all depend on your environment and the choices you’ve made for your domain. Each one is different, like an adventure.
If you did not plan ahead before going forward with your migration, have your resume handy, because you’re embarking on a different kind of adventure.