Last updated on April 29, 2021.
Between them, these two DNS architects have 45 years of experience, most of it helping folks migrate DNS platforms. They’ve seen it all. Helped hundreds of enterprises make the transition. Minimizing anxiety. Maximizing up-time. And generally treating each migration as a custom job.
Their approach: A proven methodology that faithfully and correctly considers the customer’s business objectives, and stays true to those. To give you an idea of the detailed steps involved, read on:
- Conduct a full analysis of the architecture and customer data
- Identify and outline the correct solution
- Stand up the infrastructure (whether with hardware or virtual machines)
- Do multiple dry runs to make certain the customer is satisfied
- Ensure that all data is migrated over, after stale data is scrubbed
- Move the data to production-quality services
- Create several maintenance windows, as necessary, to cut services over
A careful process is followed for each migration. Completion times vary widely, depending upon the size complexity of the installation.
These pros make it look easy. Still, there are always concerns with such a sensitive and business-critical undertaking. “Table stakes” is how Chris Buxton describes his commitment to making sure everything works the way the client’s old DNS solution did – or better – and delivers a superior experience to their end user.
Here are the top four questions migration teams are consistently asked:
- Will the new solution do everything the old one did?
- How similar will the new systems and processes be to what we’re accustomed to?
- Will there be a different user interface?
- How can we leverage APIs for other services?
In VitalQIP migrations, there are always questions around the Options template. BlueCat, instead, uses an innovative “Inheritance Model” that can be set higher up in the object tree, and is then “passed down” through the network to accomplish what the Options template does. Previous QIP customers who have migrated to BlueCat have embraced this solution.
Nothing beats seeing how things will actually work in the new DNS environment. That’s why a step in the standard migration methodology is to import the data into a lab environment for review, testing, and general poking and prodding. This User Acceptance Testing step is part of the dry run process mentioned above, but can also be done right at the beginning, or even before the migration project, to ensure that the new solution will in fact meet the needs of the business. In that staging area, customers see their own data, ready for deployment to DNS/DHCP servers.
Customer Migration Stories
It’s always helpful to hear how other companies have successfully made the move, and see how their challenges were handled. Some of the world’s largest enterprises have trusted their DNS migration to BlueCat: TJX, Kaiser Permanente, CSC (now AT&T), Zurich and Apple.
Here are a few migration projects recently completed.
Recognize any of these challenges in your network infrastructure?
Customer Migration Challenge #1 – Dynamic DNS for 1,000+ of retails outlets
This large project, consisting of scores of dual-purpose servers, called for replacing the company’s entire infrastructure. All remote users and updates relied heavily on Dynamic DNS. Security breaches had become a serious concern, and with over 1,000 retail locations, any downtime was an issue. The customer’s licensing and support contracts with an alternate vendor were expiring, so timing was critical.
This migration was complete with 40 percent fewer servers, the majority of them dual-purpose DNS/DHCP. Client Dynamic DNS updates were enabled between QIP and BlueCat. Cutover happened in a single day. DNS downtime was Zero time, and DHCP downtime was less than 2-3 minutes per server, per cutover. To boot, the entire project came in under budgeted hours.
Customer Migration Challenge #2 – Multi-phased migration
This scenario demanded a multi-phased migration approached and required a DNS resolution framework for end users.
It took eighteen distinct phases to complete this install. The methodology and toolset developed to support those multiple phases has now become a standard, as well as the DNS resolution framework for end users.
Customer Migration Challenge #3 – From outsourced to in-house
A brand new network management team at this organization took on the legacy of an outsourced network. To bring it all in-house, all DNS servers had to be replaced, and they needed a reliable way to manage risk and cost. The customer was seeking a solid go-live process; and moving large amounts of data was a key consideration in this migration.
Every server was replaced for this customer – and two additional layers were added for better functionality: an authoritative layer to segregate authoritative duties from recursive duties, and an internal recursive layer to recurse out to the internet. The team expanded the client’s network to the cloud, initially on AWS (with an eye to Azure in the near future) for easy network management. To deal with the massive amounts of data migration, operations were frozen for short intervals so the client could collaborate with the migration team to port it over.
Expert DNS and DHCP migration for any enterprise, large or small, is done with planning and validation of every step, at a pace that accounts for risk tolerance and best practices. BlueCat’s proven methodology has allowed customers large and small to migrate successfully, often without end users even aware the project is underway.
That’s how BlueCat does it.
Spend 3o minutes with Chris Buxton and Reese Cline to hear just how manageable Adaptive DNS migrations can be.
Two levels of BlueCat support offer health checks to analyze customers’ system data for potential problems and fix them before they take networks down.
New features tame network complexity, reduce costs, improve security, and automate DDI tasks to drive rapid innovation.
Whether you’re a newbie or an expert, BlueCat training offers self-paced online learning, instructor-led training, and expert certification badges.
Learn how the Java-based Log4j2 logging vulnerability works, how severe it is, its potential effects on BlueCat products, and what has been done to fix it.