I am a hands-on guy. If I need to change a switch or a setting on a network, I draw up the schematics and get started. But sometimes it is good to take a step back and see if that is the most efficient way to do the job. This is my second after-summer resolution.

Years ago when I was purely a consultant, I was asked to supervise the migration of a network from one ISP to another. And both parties couldn’t be more different than the sun and the moon. The ISP that wanted to migrate the network, the sun, was all about documenting every step that was taken for this migration. Every setting had to be written down and for all those settings we had to write down how it worked and what could go wrong during or after the migration. It was almost like the bigger the document was, the better.

It was tedious work and at the time I was doing it, I felt that maybe it was a bit too much to write everything down.
The other party, the moon, was the complete opposite. They got the order, scribbled down some settings, started with the migration and dealt with any issue on the fly. If something didn’t work as it was supposed to, they tried something else until it did. Which to me – at the time – felt much more the natural way of working. It got the job done.

I am not saying that working one way or the other is the best way. What I can say though, is that the migration of the network from the sun to the moon took nearly two years. Later on, everything had to be migrated back, and that took only six weeks…

Documenting your steps is a very useful way to prepare for any change or migration. It allows you to take a step back and think about all the consequences. Also, if you have written down the commands already, it is just a matter of copy and paste those commands, instead of typing them all over again. So it is definitely a way for me to get an even better insight of the changes we are about to make. Besides, who am I to ignore my own advice?