Network & Firewall Migration Guide

This is an original planning guide. It is not a vendor manual, an official standard, or legal advice. Example addresses use documentation ranges. Review every command before you paste it.

A migration is a rehearsal with a rollback

Moving from one platform to another, or from one design to another, is a project with a night in the middle. The night is the small part. The inventory, the translation, the rehearsal, and the rollback are the project. A converter that emits a configuration is a draft. It is not a migration. Someone who knows both platforms has to read it.

This desk has converters between a few dialects. They run in the browser and they tell you to review every line. Believe that. A translated ACL that is wider than the original is a security incident you scheduled. A translated route that points at the wrong next hop is an outage you scheduled. The tool did not know your next hop. You did.

Do not migrate what you cannot name. An inventory of prefixes, peers, VPNs, management addresses, and the one server that is single-attached is the start. The device that nobody documented is the device that fails at 1 a.m. Find it in the rehearsal, when the old platform is still carrying the load.

Parallel running beats a heroic cut. If you can have the new device beside the old one and move one prefix, do that. A big bang is what you do when parallel is impossible, and then the rollback has to be faster than the outage you are willing to have. Time the rollback. If it does not fit, the design of the night is wrong.

What the inventory must contain

Every prefix the old device routes, and why. Connected, static, and learned. A learned prefix you did not know you depended on will not be in the new static design unless you saw it. Dump the table while the network is healthy. The night of the migration is a bad time to discover a branch.

Every peer: routing, VPN, management, and the directory the logins use. A firewall replacement that forgets the VPN peer is a branch outage even if the LAN ports are perfect. The VPN guide's rule applies: both ends move in the plan, even if only one end is the device you are replacing.

Every exception. The server with one cable. The fax line. The door phone. The ACL that exists because of one incident three years ago. Exceptions are the migration. The happy path is the easy part and it is the part the converter will get closest to right.

Names. DNS may point at addresses you are about to change. Lower the TTL before the night, as the DNS guide says, or accept that clients will keep the old address. A migration plan that does not mention DNS will be blamed on the firewall.

Translation is a review, not a button

Take one interface, one VLAN, one route, and one policy. Translate them. Read them beside the original. Then lab them. If you cannot lab, do not migrate that feature on the first night. Leave it on the old device or do not promise it.

Watch for silent widening. A tool that turns a named object into any, or a specific port into IP, has made the policy worse. Diff the intent, not the character count. The hardening guide is the standard you are trying not to fall below. A migration that weakens management access is a failed migration even if the users are happy.

Watch for silent narrowing too. A VPN that comes up and carries nothing will be called a routing bug. Check the allowed prefixes on both ends. The converter does not know the remote peer's view. The remote peer's view is a phone call or a second window, not an assumption.

Keep the original configuration in a store you can reach if the new device is a brick. You will want a line from it at 2 a.m. A configuration that lives only on the device you are about to wipe is not a backup. Take it first. Confirm you can open the file. A backup you cannot open is a story, not a backup.

The night, after the rehearsal

Rehearse the whole sequence on the lab or on a quiet prefix. Time it. The production window is that time plus the rollback time plus slack. If the business gave you less, move less. One prefix that succeeds is a migration. Fifty prefixes that half-finish are an incident.

Move management last or on a path that survives. If you manage the new device through the network you are moving, a bad route locks you out. The automation guide says the same thing. A console or an out-of-band path is part of the kit, not a luxury.

Have one test host per prefix you move, with an owner awake. You ping, they try the application, you both write the result. A ping is not the application. The fundamentals guide's return path still applies. Test the reply and the name.

Stop conditions are written before the night. If the first prefix fails its test, you roll back. You do not push on because the window still has hours. Hours are how a small failure becomes a large one. The rollback is the success condition you already accepted when you wrote the plan.

The morning after

Compare the live table to the inventory. Missing prefixes are the work of the morning, not a surprise for next week. Extra prefixes are too. A documentation prefix or a lab route left in the new device is a defect. Remove it.

Watch monitoring. The monitor guide's alerts should have followed the devices. An alert still aimed at the old address is an alert that will page about the wrong thing and stay silent about the right one. Move the checks as part of the migration, not as a tidy-up.

Tell the people who were awake what actually moved. The plan and the night often differ. The record of the difference is the only way the next migration gets shorter. A migration with no notes will be repeated, mistakes included.

Decommission the old device only after the rollback window you promised has passed. A device you wiped at dawn cannot save you at noon. Power it down, do not wipe it, until the business agrees the new path is the path.

Inventory prefixes, peers, exceptions, and names.
Back up the old configuration and prove you can open it.
Translate a small piece and lab it.
Diff the policy for silent widening.
Time the rehearsal and the rollback.
Move one prefix with an owner awake.
Stop and roll back if the first test fails.
Keep the old device restorable until the promised window ends.

Mistakes that schedule the outage

Treating a converter draft as a finished configuration.

No inventory of learned routes.

DNS TTLs left long.

Management that depends on the path being moved.

No timed rollback.

Pushing on after the first prefix fails.

Wiping the old device at dawn.

A policy that got wider in translation and nobody diffed it.

Migration checks before the night is booked

Confirm this before you call the change done: The inventory includes learned routes, VPNs, and the single-attached server. A backup of the old configuration opens on a machine that is not the old device. One translated policy was diffed for widening and narrowing. The lab used the same software family as the new device. Rollback time plus change time fits the window. DNS TTLs were lowered early enough. Out-of-band management exists. The first prefix has an owner who will test the application. Stop conditions are written. Monitoring targets move with the devices. The old device will not be wiped until the rollback promise ends. Documentation and lab prefixes are not in the new production configuration. A second person read the allowed prefixes and the routes. The converter's review warning was obeyed, not clicked past. Learned routes were dumped while the old network was healthy. The remote VPN peer is in the plan, not only the local firewall. The first prefix's application owner is awake for the test. Rollback time was measured, not guessed. The old device stays restorable until the promised morning window ends. And monitoring was pointed at the new addresses before the old ones were silenced. If one of those fails, stop.

Tools for this guide

These tools run in the browser on this site. They do not log into your machines.

Guides in this cluster

These supporting pages belong to this pillar.

Companion: Security: Server Hardening Guide.