Cleansing DDI data is the most important part of a migration
Migrating DNS, DHCP, and IPAM (DDI) is an inherently risky business. It’s the network equivalent of open heart surgery – changing out the connectivity mechanism for every device and server on your network without incurring any downtime. With all of the configurations and routing pathways involved, there’s a lot that can go wrong.
It’s surprising, then, that many DDI companies have a “lift and shift” approach to migrations. In many cases, they seem to assume that moving from legacy to purpose-built solutions is something that should be done as fast as possible. Yet by prioritizing speed, they often increase the very risk of downtime that makes network admins wary of DDI migrations in the first place.
The problem with quick “lift and shift” migrations is that misconfigurations and bad data move from one system to the other, essentially replicating the dysfunctionality of legacy DDI systems in a new solution. It’s basically the equivalent of planting a time bomb in your core infrastructure. Rather than dealing with these problems up front in a systematic way, the network team is left to pick up the pieces when something goes wrong at an unpredictable point in the future.
What bad DDI migrations look like
It’s not like these data errors and misconfigurations are rare. When BlueCat migrates customers over from decentralized “solutions” like Microsoft and BIND, we uncover issues all the time. Here are some examples of what we usually discover:
DHCP lease times: When DHCP is managed through spreadsheets, lease times tend to be all over the map. There’s no rhyme or reason to how lease times are assigned. When we migrate networks to BlueCat, we standardize lease times around user personas and device types, making the enterprise much easier to manage in the long term.
DNS TTLs: The time to live (TTL) settings in decentralized DNS solutions also tend to vary quite a lot. Non-standard TTLs can amplify misconfiguration problems, chewing up bandwidth by allowing constant queries to non-existent sites. When we migrate DNS to BlueCat, we identify device specific TTLs that make sense and standardize them across the enterprise.
DHCP/DNS options: In decentralized systems, the use of DNS and DHCP options tends to proliferate. This creates a lot of option redundancy, making the infrastructure harder to manage over the long term. During a BlueCat migration, we optimize option settings so administrators can modify options in a single step.
Bad IPAM data: A lot of the IP address management data we see is just plain incorrect. This is one of the main issues with spreadsheets – old assignments aren’t updated. In the worst case, this can result in IP address conflicts which bring down the network. In a BlueCat migration, we pay very close attention to IPAM data, ensuring that potential conflicts are cleansed before we move into production with a new system.
Any of these challenges would be concerning if they occurred in isolation. In our experience, however, pretty much every network we see has all of the above issues. The problem of bad IPAM data is particularly common, even (or especially) when enterprises have tried to limp along with a split solution where IPAM is managed separately from legacy Microsoft and BIND solutions for DNS and DHCP.
BlueCat’s approach
For all of these reasons, the BlueCat migration team puts special importance on cleansing DDI data. We know from experience that the risk associated with any core infrastructure is real. Even more, we know that prioritizing speed over quality during the migration process can have serious implications down the line.
That’s why we’ve developed a systematic process and unique tools which cleanse DDI data long before it migrates over to BlueCat. We run everything through our custom-built platform to identify any outliers and flag potential problems far in advance of any cutover. We’ve also developed a new way of gradual migration which allows for automatic failover to a previous system in the event that a misconfiguration or bad data slips through our filters – yet another way that BlueCat ensures the integrity of our customers’ enterprises.
In addition to our technical tools, BlueCat also places special emphasis on connecting with our customers, to really understand the reasoning behind their network architecture. Sometimes what we consider a misconfiguration is rooted in a solid operational logic or business priority. That’s why we take the time to ask before we change anything, rather than simply porting everything over blindly.
Learn more about BlueCat’s unique DDI migration process.