Example scope: replace one office firewall

Imagine a fictional office with employee, voice and guest networks, one internet circuit and a site-to-site VPN. The agreed project replaces the firewall while retaining the existing switching, addressing and phone provider. Changing the internet provider, redesigning every VLAN and replacing access points are outside this example. Keeping those boundaries explicit makes validation and rollback easier to understand.

The business needs staff access to its cloud applications, working calls, access to a remote application over the VPN and continued separation of guest traffic. The plan lists those outcomes before it lists configuration tasks. A device that powers on and reaches the internet has not yet passed the business acceptance checks.

  • Change owner: approves scope and the maintenance window
  • Implementing engineer: performs and records the authorized steps
  • Business validator: tests representative applications and calls
  • Rollback authority: can stop the change and restore the baseline

1. Capture the baseline and dependencies

Record the current topology, physical connections, interface roles, routes, VLAN boundaries, VPN peers, relevant policy and translation behavior. Identify services that depend on DHCP, DNS, authentication, certificates or public addresses. Obtain a protected configuration backup and verify that authorized staff can retrieve it if the office network is unavailable.

Run the acceptance checks on the existing environment first and record the results. If a phone already has one-way audio or a VPN application already fails, the migration record must say so. Otherwise the team can waste the maintenance window investigating an unrelated condition or accept a result that was never actually tested.

The baseline also records known limitations: an unavailable application owner, incomplete logs or a device whose support status needs confirmation. An unknown dependency belongs on the readiness list with an owner and disposition. It should not disappear simply because the cutover date is approaching.

2. Make the go/no-go decision before disconnecting anything

Confirm that the replacement equipment, software, licenses and required features are ready. Review the proposed configuration against the intended traffic behavior; translating commands between vendors is not enough. Where feasible, stage the replacement and test representative functions before moving production connections.

The team needs a working management and recovery path, labeled connections, a reachable business validator and permission to use the maintenance window. Confirm how the original device will be restored and whether any shared or external dependency makes that restoration difficult. If a prerequisite is missing, the change owner decides whether to reschedule or formally revise the scope.

  • Approved scope and protected, retrievable baseline
  • Replacement configuration reviewed and staged where feasible
  • Physical connections labeled and restoration steps documented
  • Required technical and business contacts available
  • Acceptance tests and rollback authority agreed

3. Use a cutover sequence with checkpoints

An illustrative sequence is: confirm the baseline, capture the final backup, record the start time, place the old equipment in the agreed recoverable state, move the labeled connections, establish management access and check interfaces and routes. Then validate the required application paths. Record who performed each step, the time, the expected result and the observed result.

The sequence must be adapted to the actual platform and topology. High-availability pairs, shared public addresses, dynamic routing and remote-only access can require different preparation. This example intentionally omits device commands because commands without the environment and recovery requirements would create a misleading impression that the plan is ready to execute.

4. Define rollback triggers and the decision deadline

A rollback plan needs both a technical procedure and a decision rule. Example triggers include loss of the approved management path, an unexpected security boundary failure or inability to complete a critical business test within the agreed troubleshooting allowance. The person authorized to invoke rollback must be reachable and able to act without a lengthy new approval chain.

Suppose a fictional maintenance window ends at 10 p.m. and the team has validated that restoring the old equipment and repeating essential checks needs 45 minutes. The latest rollback start would be 9:15 p.m. Additional contingency time would move the decision earlier. Those numbers illustrate the calculation; they are not a time estimate for your network.

Restoring the old firewall is not the final step. Repeat the baseline checks, verify administrative access, document any residual issue and notify the authorized business contact of the actual state. Keep evidence from the unsuccessful cutover so a later attempt addresses the cause rather than repeating the same assumptions.

5. Record acceptance evidence for each business path

Each check needs a source, destination or service, expected behavior and observed result. Test permitted paths and important prohibited paths. A successful employee connection does not establish that guest devices remain isolated. A VPN showing connected does not establish that the intended remote application works.

Use representative authorized devices and application accounts. Record timestamps and relevant log references without placing credentials or unnecessary personal data in the handoff. The business validator confirms the agreed user workflows; the engineer confirms the supporting network observations and documents the limitations of the tests.

  • Employee device → required cloud application: expected access succeeds
  • Authorized endpoint → remote application across VPN: agreed workflow succeeds
  • Representative phone → agreed call tests: expected audio works in both directions
  • Guest device → internal business resources: required isolation remains effective
  • Authorized administrator → management path: access and logging work as agreed

6. Hand over a record someone else can use

A useful handoff contains the final diagram, relevant inventory, approved configuration record, completed acceptance checks, change log and unresolved issues with owners. Record where protected backups are stored and who owns ongoing maintenance. Include the observation period and escalation arrangements that were actually agreed; do not assume the project creates continuous monitoring or an emergency support service.

The preparation engagement can produce a runbook for your own team to implement. A separately scoped deployment engagement can include execution and the agreed validation. Keeping those deliverables explicit helps the buyer compare proposals and understand exactly what responsibility is being purchased.

Use this example to evaluate an engineering proposal

Ask whether the proposed work identifies the business services at risk, evidence needed, dependencies, acceptance criteria and rollback decision. Ask which assumptions still need testing and who is responsible for each unresolved item. A well-scoped engagement should leave you with a usable record even when the evidence shows that the change is not ready to proceed.

Wolex offers scheduled network migration preparation, design and deployment for Portland-area businesses and internal IT teams. Share the intended change, approximate device or site count and preferred timing through the inquiry form. Scope, availability and price are agreed before work begins; sensitive configurations and credentials are handled only through an agreed process.