The starting point

Let's be honest about where most teams are. Someone SSHes into a server and runs dnscmd. Someone else uses the AWS console. A third person has a PowerShell script that "mostly works." There might be a shared spreadsheet tracking changes — or there might not. When something breaks, the first 20 minutes are spent figuring out who changed what, because there's no single place that records DNS history.

This isn't a failure of the team. It's the natural result of DNS being "someone else's problem" that grew organically. DNS management was never a priority until it caused an outage, and by then the ad-hoc approach was deeply ingrained.

If this sounds like your team, you're in the majority. And migrating to a controlled workflow is less painful than you think — because the goal isn't to replace everything overnight. It's to introduce visibility and control incrementally, without disrupting operations.

Why teams migrate

Teams don't migrate because they read a blog post about best practices. They migrate because something happened:

Whatever your trigger, the migration path is the same. The timeline just depends on urgency.

The migration in 5 phases

Phase 1: Assessment (2-4 hours)

Before you change anything, map what you have. This is a discovery exercise that answers four questions:

Don't overthink this. A quick inventory on a whiteboard or in a doc is enough. The point is to understand scope, not to document every record.

Phase 2: Import (30 minutes per provider)

Import your existing records into Netra. This is a read-only operation — you're taking a snapshot of current state, not modifying anything on your providers.

After import, you have a complete picture of your DNS state in one place — often for the first time ever. This alone is valuable. You can see all records across all providers, find duplicates, spot orphaned records, and identify conflicts.

Phase 3: Shadow mode (1-2 weeks)

This is the critical phase that most teams skip — and then regret. During shadow mode, Netra runs alongside your existing processes. The team submits requests through Netra and continues making changes the old way. Nothing is enforced yet.

Why? Three reasons:

During shadow mode, treat drift alerts as informational, not as violations. The team is learning. When drift decreases naturally because people prefer the new workflow, you know you're ready for cutover.

Phase 4: Cutover (1 day)

Once the team is comfortable with the workflow, make it the only path. This is a single-day event:

  1. Restrict direct access. Update IAM policies, remove console write permissions for individuals, revoke standalone API credentials. Write access goes through Netra only.
  2. Activate the approval workflow. Enable the two-person rule for production zones. Configure who can approve what — maybe senior engineers approve production, anyone can approve dev.
  3. Connect notifications. Set up Slack or Teams notifications with one-click approve/reject buttons. The approval path should be zero-friction from day one of enforcement.
  4. Communicate the change. Send a brief message to the team: "Starting today, all DNS changes go through Netra. Here's the quick-start guide. Here's the emergency bypass procedure."
  5. Set drift alerts to active. Drift is no longer informational — it's now an actionable alert that means something bypassed the workflow.

Keep the cutover day light on other work. Be available to answer questions, help with the first few real requests, and tweak notification routing if needed.

Phase 5: Optimization (ongoing)

Once the basics are running, layer in additional capabilities as the team gets comfortable:

There's no rush here. Optimization happens over weeks and months as the team identifies patterns and repetitive tasks that can be streamlined.

What NOT to do

Common mistakes teams make during migration — learn from others' pain:

Don't migrate everything at once

If you have 50 zones across four providers, don't try to import, configure, and enforce all of them simultaneously. Start with your most active zone — the one that changes most often and causes the most coordination headaches. Get that working smoothly, then expand. A successful migration of one zone builds confidence for the rest.

Don't remove console access on day one

Shadow mode exists for a reason. If you lock down access before the team trusts the new workflow, you'll create resentment and people will find workarounds. The sequence matters: demonstrate value first, then enforce.

Don't skip the import step

Drift detection compares live state against a known baseline. If you don't import existing records, you have no baseline, and drift detection can't work. The import gives you your starting point — every record that exists right now, documented and visible.

Don't forget emergency procedures

Before enforcement day, document and communicate the fast-path for emergencies. What happens at 2am when the approver is asleep? Options include: bypass with full audit trail (the change goes through but gets flagged for post-hoc review), designated always-available approvers in different time zones, or self-approval with mandatory justification. The specific answer depends on your team — but having no answer means people will find their own (untracked) emergency procedures.

Timeline expectations

This isn't a 6-month migration project. Realistic timeline for a team of 5-15 engineers:

Most teams are fully operational within 2-3 weeks. The migration is low-risk because shadow mode lets you validate everything before enforcement, and the import step is non-destructive (nothing changes on your providers until you submit a request through the workflow).

Team adoption tips

Technology is the easy part. Getting people to change habits is harder. A few things that work:

Keep it simple at first

Don't enable every feature on day one. Start with submission and approval only. Skip scheduled changes, bulk operations, and CI/CD integration until the basic workflow is second nature. Feature overload kills adoption.

Celebrate the audit trail

The first time someone asks "who changed this record?" and you can answer in 5 seconds instead of 5 minutes — make that visible. Share it in the team channel. The audit trail is the most immediate, tangible benefit. Let people experience it.

Make approvals frictionless

If approvals are slow, people will resent the process. Set up Slack/Teams one-click approvals before enforcement. If the average time from submission to approval is under 5 minutes, nobody will complain about the extra step. If it's 2 hours, they'll find workarounds.

Don't enforce the two-person rule immediately

Start with self-approval enabled (with audit trail). Let the team get comfortable submitting requests through the workflow before adding the approval gate. Once submission is habitual, adding the two-person rule is a minor adjustment — not a major process change.

Address the "but I know what I'm doing" objection

Senior engineers who've managed DNS for 15 years don't want to feel like they need permission. Frame it correctly: the workflow isn't a gate on their expertise — it's a record of their decisions. Six months from now, the audit trail will prove they made the right call. It's professional documentation, not bureaucratic overhead.