I work in the US Healthcare industry… it is by choice, no need to apologize.

The entire healthcare infrastructure of the US is currently undergoing a state by state consolidation due to market pressures and regulation. This has caused an acquisitions adventure for my employer and this is a list of my Technical and Project Management lessons learned. The process is fraught with complex technical issues that will span departments, companies, and political boundaries… proceed with caution.

Build A Team. You will need a team and a phased approach to involvement. Your Networking resources will be deeply involved in the early phases and the late phases. Your client and app support teams will need to be engaged in the mid phase, and somewhat in the late phase. Your Active Directory/Security/Mail Admins will most likely be involved nearly the whole project.

Be ready for these resources to be dedicated to your acquisition project. If they are working on this, it will be difficult for them to multi-role to any significant degree when they are engaged on this project. As a corollary, if your company is going to be engaging in a buying spree, consider creating a technical acquisitions team and putting it out on it’s own as a dedicated project team until the growth is slowed.

Utilize professional resources and contractors if at all possible. Have your resources shadow them, and in time you may be able to rely less on the consultant dollars. Expect that consultants WILL be needed when building the budget for a new acquisition. It may seem expensive on paper, but a botched migration will cost far more than the contract resources would have. Establish Policies and Procedures. Establish security baselines. Decide, and get in writing, what the baseline for importing the source companies’ resources into your environment (Virus Scan/Patching level).

Decide what your IP Scheme will look like. Analyze what the source environment looks like currently. Define what the new IP scheme will need to be. It is important to plan to make the new environment compliant with your existing infrastructure.

Analyze VPNs here. Supporting those tunnels will become incredibly important once the migration begins.

Decide how you will import source Domain’s objects into AD, and what the AD structures will look like. Make them compliant to what you already have If you intend to migrate the objects into your root domain; but I would strongly advise considering adopting sub-domains if you haven’t already. Often times if your business is on an acquisitions spree, you may one day find yourself selling a facility or company… sub-domains can help to make that far less messy and they simplify the syncing of email and GAL. Establish Cloud Based Access To Critical Business Resources. Private, Public… Whatever Works. If you have a Citrix Web interface, leverage it to extend critical services to the new environment right up front.

Consider at this phase taking management of the source Application Delivery infrastructure. It will allow you to begin to get a handle on what is required on a wider scale to integrate the legacy systems. Exchange GAL Sync. Utilization of a tool like QCS will allow you to synchronize the GAL and have user’s objects stamped with their new domain email addresses. This product is usually implemented once a business need is determined for email to share the Domain-Name Convention of the new parent company. The number one business driver of this, in my experience, has been new business cards with the new SMTP address. Executives want it bad… real bad… like in some cases, several hundred thousand dollars bad.

This piece can be done over the internet securely, and doesn’t have to wait for the two-way trust. Secure the Endpoints. Make sure your patching baseline Is compliant in the source environment.

Make sure all clients and servers are running Anti-Virus of your choosing.

Consider if you wish to implement intrusion detection devices at the network perimeters as an added layer.

As stated previously, having an iron-clad agreement on what constitutes “secure” is important. Get buy-in and execute to that expectation. If you do not, this project will spiral into a “replace all the endpoints” scenario, and will get expensive in a hurry. Extend Your Network. The best way to do this is to consider a DMZ style network. The new network segment should be allowed to route to both the source network and to the target network, but no traffic should be allowed to cross this “non-DMZ” network into the other in the initial phase of the migration. Re-IP All The Things. Give the new team members on-site their first REAL local project. Have them re-IP all of the devices on their network to match your new IP scheme in the new network. This will avoid the more complicated step of re-IPing devices as they are processed in the migration. Configure The External Trust. When configuring the two-way trust for use, you will need to ensure that all DCs have routability to each other, and more specifically that authentication can be carried out properly. This is why the re-IP step above is essential in this process. The two-way trust is required before you begin the migration.

Make sure to allow your AD experts to set their requirements here. A lot of hand-wringing can happen here, as to most AD is a very mission critical black box. There’s a reason that this one comes after “Secure the Endpoints”, I’ll let you do the math on that one. Begin Domain Migration. Be mindful that when migrating resources into a new domain that any systems that are AD integrated will migrate fine if you use a well configured migration tool such as ADMT, or Dell Migration Manager. If they have stand-alone security databases they will also move and maintain security pretty flawlessly. If there are LDAP integrated, or domain integrated DB (SQL) security you will need to jump through a few hoops to maintain functionality. This will vary widely between applications. Items Of Note: Your executives and politically important users will always want to go first. Don’t do it. Hold them off until at least mid-migration. Early adopters are more likely to experience untested and undiscovered problems. If they are a high value target in the environment, they may quickly try to shut the project down, or cause other headaches that could easily be avoided if they were migrated more toward the later stages of the project.

Do not create permanent user accounts on the target domain for the new users ahead of migration. Allow that process to be handled by the migration tools. If a new user is created utilizing the standard methods for a new user, this complicates the migration. You should always expect there to be exceptions, but try to keep them to a minimum, or make sure the user has no mailbox on the account in the target domain. Merging accounts can be tricky, let the tools handle it natively as much as possible.

If a facility or company is up for sale for a while, it is often likely that IT resources have been the last thing on the budgetary requirements list. Be prepared that much if not all of the equipment in use is old and not terribly compliant. When these entities are purchased, one should consider including cost of total infrastructure updating/replacement, and be pleasantly surprised if they do not incur said cost.

I have a secret formula for determining if the endpoint count is correct. I won’t share that. I have to keep something to make a living with.