Fieldnotes on

Infrastructure Migration Checklist

Sat, 13 Jun 2026 21:31:13 +0200

Throughout the years, I watched how infrastructure migration projects succeeded, partially failed or created chaos right after a cutover action. And the accuracy of predicting a failure increased with a decrease in clarity just before the cutover. I’ve collected the following items to increase the success rate of any migration work, assuming that previous project phases have been dealt with:

Involve packet capture and analysis early in the migration project.
Establish a communication matrix of the current infrastructure.
Evaluate, discuss and agree the fidelity level of the communication matrix, i.e. the level of accuracy with which it represents the current infrastructure. The more accurate and comprehensive the matrix is, the less headaches and cognitive exhaustion the project team will have during the cutover.
Define the possible outcomes. This should include description of the expected technical infrastructure as well as the client-facing services that should resume working after the cutover. To minimize decision hesitation among stakeholders, define a Minimum Viable Outcome (MVO) document.
Elaborate a rollback plan that works. The validation of the rollback plan occurs in stages, where each stage starts with the finalization of each design module.
Define the order of execution of the migration steps using precise wording and include micro validation checks. An incomplete example is “implement security rules, implement OSPF routing then do a show ip route ospf”. A better example can be “Implement ruleset RS1. Verify reception of OSPF routes X1, X2 and X3.
Involve all possible stakeholders, including power users that have adequate access to the business applications. Ensure their work shift matches the project change window.
Establish active horizontal communication: This is the most trivial communication mode, where members of the project inner team exchange thoughts, agree on procedures and execute steps.
Establish active vertical communication: Keep the Team Lead / Director / CTO / CIO always informed on the recent developments of the project, the current issues and alignment with the project deadlines.
Establish Change Windows and Change Freeze Windows. Communicate them to the stakeholders.
For every traffic pattern of the current infra, there should be a corresponding traffic pattern in the target infra. Each traffic pattern of the target infra is ideally tested, documented in an isolated environment and discussed with the project team long before the cutover.
Capture the infra state: This involves for instance documenting the location of the IP default gateways, the router MAC addresses, NAT rule locations, DNS usage, etc.
Whenever suitable, plan redundant human resources that can execute assigned cutover actions in lieu of the primary resource. Physical sickness does not have an outlook calendar.
Avoid unecessary tensions. Even with good preparation, sensitivity to stress and potential for misinterpretations increase on a migration day.

Infrastructure Firmware Upgrade: Beyond CLI Commands and Change Windows

Wed, 03 Jun 2026 21:31:13 +0200

When a piece of infrastructure needs a firmware upgrade, most engineers and consultants typically think of two things:

the set of CLI commands to enter on each individual device,
the date of the maintenance window. A proper firmware upgrade is much more than that. Here is my framework for infrastructure firmware upgrades, which remains relevant whether we are dealing with CLI-managed devices or software-defined GUI-based controllers. I dissect it into the following phases.

Alignment phase

Define scope of work.
Explain the intended preparatory work and align it with customer expectations.
Define the responsibilities.
Define the nature of the interaction with the customer: preferred and reasonable type of communication (calls, workshops), remote vs onsite, frequency.

Deliverables and Output

Scope of Work
RACI Matrix

Discovery phase

In this phase, the following data must be gathered:

Service Graph Rendering Expectations vs Reality

Sat, 23 May 2026 11:31:13 +0200

Creating a Service Graph Template, applying it and not finding any faults is one thing. Seeing the rendered Service Graph is another thing.

Observation

The rendering of a Service Graph Template is dependent on the following:

existence of two EPGs with a contract relationship,
existence of an association between the contract and the Service Graph
existence of contract-matching traffic, i.e. the existence of traffic that matches that contract. As soon as that contract is attached to the Service Graph Template during the “Apply Service Graph Template” phase, then that is the moment where the Service Graph Instance appears in the APIC GUI.

Critique

When I look for the requirements for deploying Service Graph Redirects in the ACI Service Graph Whitepaper document, the assumption mentioned in the ‘Configuration’ paragraph reads a bit vague: The activation condition of a Service Graph Template remains open and can only be clarified with these questions:

Working as a Network Engineer

Sun, 08 Sep 2013 21:31:13 +0200

When you work in Operations and you tell your internal clients that you work as a network engineer, they often think that you are “Mr All-computer-stuff”. That is often the case regardless of where the client is in the company hierarchy. They expect you to fix any computer issue they have at hand. Onsite interventions feel like you were dropped in a tribal region in a forest while equipped with a Swiss-army knife.

Your Phone Conversation Started Earlier Than You Think

Sun, 08 Sep 2013 21:31:13 +0200

Something that I noticed over the years, after countless phone calls I’ve had with co-workers, managers, service providers and clients, is that people react best to your message if you talk to them as if they were physically in front of you. It’s not because your voice sounds different on the phone that you treat people in a mediocre fashion. It’s not because the other person is far away that you can afford to downsize him or her. I even find myself gesturing like I was giving a speech in front of deaf people! Does that mean that I should pay attention to my facial expressions? To some extent yes. But, the universal emotions of joy, sadness, anger and deception can definitely be wonderfully encoded in your voice while on the phone. That is the reason why the smile of a caring customer service agent can not be mistaken. And that makes the other person comfortable and very receptive to you.

TSHOOT Exam Feedback

Thu, 26 May 2011 21:31:13 +0200

Finally, I passed. I feel so happy that two years of discontinuous study and a lot of frustration paid off. I deserve this nice recognition :) Now, I can tell that it takes a LOT of patience, focus and self confident to pass not only this exam, but the whole track. Why? because many guys fall in the trap of cramming questions in order to become CCNP fast. I began the CCNP journey in 2009. I only became CCNP in 2011! Some guys may tell me that I was not serious about my studies. But here are my arguments:

TSHOO Exam Day is Near

Tue, 24 May 2011 21:31:13 +0200

Two days are left before my TSHOOT exam. I feel confident about it since I have a first taste of it. I read feedback given by test takers that it is a a nice experience. I ought to be ready for both scenarios. If I succeed, then I know that all my limiting beliefs about CCNP were false. Then, I’ll know that I was prisoner of my false beliefs. And if I fail, then I should remind myself about all the courageous people in the IT world who spent a lot of money and time in the pursuit of their certs. Either way, I’ll learn something, and that’s my own choice. I made my choice to enhance my career, no matter what the sacrifices are. “Courage is resistance to fear, mastery of fear - not absence of fear” - Mark Twain