5 Tips for Migrating to Kea

Wondering what to do now that ISC DHCP has reached End of Life? Read these tips for migrating to Kea DHCP.

Notice: This blog post was originally published on Men&Mice before its acquisition by BlueCat.

The content reflects the expertise and perspectives of the Men&Mice team at the time of writing. While some references may be outdated, the insights remain valuable. For the latest updates and solutions, explore the rest of our blog

Key Takeaways
  • Migrations from ISC DHCP to Kea should be phased, starting in lab and low-risk environments to validate configurations and processes before wider rollout.
  • Kea deployments should be scheduled during low-change periods or aligned with controlled projects (e.g., new sites or AP rollouts) to minimize operational risk.
  • The migration is an opportunity to reassess DHCP architecture, potentially shifting from centralized to edge-local servers while retaining centralized management via an abstraction layer.
  • Kea’s use of an external database backend enables centralized configuration storage, online changes without server restarts, and reuse of existing database platforms and HA expertise.
  • Kea provides built-in high availability using a hot-standby server model, simplifying redundancy compared to ISC DHCP failover configurations.
  • Security can be enhanced by restricting access to the centralized database with ACLs and firewall rules while permitting broader access only to the Kea servers themselves.

In last week’s blog we discussed how ISC DHCP has EOLd. We started going over some of the ways to ease your migrations to other DHCP services. We’ll continue that discussion today with some tips and tricks for migrating to Kea.

Kea DHCP is ISC’s more modern answer to DHCP. Besides having more modern redundancy built-in to the platform it also offers a modular and extensible design, On-line Reconfiguration with REST APIs, better integration with third parties, and a web-based graphical dashboard according to ISC’s website.

So what are our tips for migrating to Kea?

  1. Migrate in chunks.

There’s an old joke, how do you eat an elephant? One bite at a time. Meaning, if you have a huge task, you can just think of it as taking one step at a time to complete.

So start your migrations off in a lab, then move to other low hanging fruit like small branches or the guest wifi or whatever might apply for you in your environment. Always testing and learning as you go.

2. Migrate during the off-season.

All engineers know that it’s best to only make one change at a time. If you’re going through a major infrastructure refresh, that’s probably not the best time to plan your Kea migration. However, maybe you have a new site you’re bringing up, or you’re rolling out new access points to enable hybrid work. That might be a good time to start implementing Kea.

This might mean that you’re running ISC DHCP and Kea DHCP at the same time, but with a DDI tool like Micetro which uses abstraction to let you manage multiple services from the same place, this should be relatively easy to manage.

3. Centralize or move to the edge?

It’s always good to think of a migration as an opportunity to change the way you’re currently doing things. If you’re running DHCP in a very centralized way, where you’re serving out IP addresses mostly from HQ because people were mostly working from HQ at the time you implemented DHCP then that made sense at the time. However, if you are now dealing with hybrid workers, several sites, or branch offices, it might be time to consider moving your DHCP servers to the edge.

DHCP can be relatively simple to implement in a decentralized way, while still managing from an abstraction layer, as you would with Micetro. Thereby having your DHCP servers in close proximity to the devices they’re serving, but still simplifying operations by centralizing management.

4. What database solution should you use?

Kea uses a backend database to store configurations which allows admins to store these configurations some place other than just on the local server. This means that configuration changes can be stored for several Kea servers in a centralized place, making management much easier. This also means that changes can be made to the database without having to restart Kea servers.

The great thing about the flexibility here, and having a separate database, is that you can use the databases and hopefully the database admins you already have! Let the experts handle the database part, including building in High Availability from a backend perspective. And building in redundancy is always encouraged at every layer.

5. More on redundancy…

ISC DHCP had failover, which was perhaps a bit difficult to configure. Kea is a bit different, in that it has built-in High Availability through the use of a hot server. So the hot server is always on and up-to-date. If something goes wrong with the first Kea server, the hot Kea server will take over.

Bonus: Make Kea DHCP more secure.

Not only can you build in layers of redundancy, due to the modular nature of Kea and having a separate centralized backend. You can also build in more security. Meaning you can build ACLs/Firewall rules around your database, as well as only allow the least amount of access to these database servers. Even if you have to allow more access to the Kea servers themselves.

How do you get started on the actual migration from ISC to Kea?

There’s a tool available now called Keama which can do a lot of the work for you. There’s some manual work that may need to be done, but Keama is probably the best tool available now. ISC has written up a KB article which may be helpful for you to get started with Keama.

As always, you can manage several services, including DNS, DHCP, and IP information all from Micetro, so it’s the perfect DDI tool to help you along with your migrations. To get started, just download the free trial and follow the YouTube Deployment playlist to get started.

Related content

Flock of geese flying in formation across a blue sky, framed by a pink graphic border, symbolizing coordinated network migrat

Automate your DDI modernization path by migrating with Micetro

Automate cross-platform DNS and DHCP migration with Micetro to reduce risk, eliminate manual effort, and modernize infrastructure faster.

Read more
Three armored figures walking toward a futuristic Las Vegas skyline with pyramids, glowing orb, and "Welcome to Fabulous Las

Your journey to intelligent NetOps begins at Cisco Live

Visit BlueCat’s booth or book a meeting now to learn more about how our solutions can help you build a network that supports constant change.

Read more
Stacked colorful wooden directional arrows on a post by a calm seaside with distant hills and blue sky

Replace BIND and ISC with Micetro DNS/DHCP Server (MDDS)

Tired of patching and manually configuring BIND DNS and ISC DHCP? Discover how Micetro MDDS appliances can replace them for modern DDI.

Read more
Row of orange industrial robotic arms positioned along an automated conveyor belt in a factory setting

Automate it all in Integrity with REST v2 API-first DDI management

Discover API-first DDI with Integrity X by using REST v2 to automate DNS, DHCP, and IPAM for scalable, secure network operations.

Read more