Before migrating, cleansing your DDI data is crucial

Migrating DNS, DHCP, and IPAM (DDI) is an inherently risky business. It’s the network equivalent of open-heart surgery. You’re 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 to do 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, it replicates 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 upfront 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. Migrating customers over from decentralized “solutions” like Microsoft and BIND unveils issues all the time. Here are some examples of what BlueCat usually discovers:

DHCP lease times

When managing DHCP through spreadsheets, lease times tend to be all over the map. There’s no rhyme or reason to how lease times are assigned. When migrating networks to BlueCat, we standardize lease times around user personas and device types. As a result, the enterprise is 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 migrating networks 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 IP address spreadsheets–old assignments aren’t updated. In the worst case, this can result in IP address conflicts that bring down the network. In a BlueCat migration, we pay very close attention to IPAM data, ensuring that we cleanse potential conflicts before we move into production with a new system.

Any of these challenges would be concerning if they occurred in isolation. In BlueCat’s experience, however, pretty much every network 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 of managing IPAM 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. BlueCat knows from experience that the risk associated with any core infrastructure is real. Even more, BlueCat knows that prioritizing speed over quality during the migration process can have serious implications down the line.

That’s why we have developed a systematic process and unique tools that cleanse DDI data long before it migrates over to BlueCat. We run everything through BlueCat’s 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 that allows for automatic failover to a previous system in the event that a misconfiguration or bad data slips through our filters. This is 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.