The VPN had been left out of the vendor migration, and the old server would shut down in two weeks. The switch was done by the Tuesday of the following week. It was not a technical trick but logistics and communication in the same hands.
Five years ago I worked at Mela, and the company was in the middle of a large migration from IBM to Tietoevry. On Monday word came that the VPN had to be replaced. It was on nobody's list. The old VPN server would be shut down in two weeks, and until then it carried the connection of 220 employees and 100 external consultants to business-critical systems.
It was the pandemic. Practically everyone sat at home at the end of a VPN.
Why it was forgotten
A vendor migration has hundreds of lines: servers, applications, integrations, contracts. The lists are made of what the vendor delivers. The VPN is awkward in that it is nobody's system. It is the pipe through which the other systems are seen. The old vendor no longer counts it as theirs, the new one does not yet, and inside the house it is "the vendor's thing".
A dependency like this is not forgotten through carelessness. It is forgotten because it belongs to nobody. That is the normal state of a migration, not an exception, which is why it is worth preparing for every time.
When it came up, I offered to do it. I had SCCM in my hands at the time, so I could build the software deployment and test it myself. That settled the schedule before a schedule had even been drawn.
What would have happened
Had the switch been late, remote work for 320 people would have stopped on the day the old server went dark. Had the installation failed on a machine, IT support could still have reached it, but the new VPN client would have had to be installed one machine at a time. With 320 machines that does not fit in two weeks.
Neither was an option. A quick package alone was not enough. I had to know what would happen on every machine, and the user had to know it before it happened.
What I did
The installation package came first, but its form was decided by the users' situation. Installing the new VPN client cuts the old VPN connection. Had the package been pushed straight over the network, the install would have cut its own connection midway and left the machine half done. So the deployment ran in two stages: the package was first copied to the machine in full, and only then did the installation start locally. The cut still came, but it no longer interrupted anything unfinished.
I wrote the instructions for the new client. Short, illustrated, one page. The user did not need to know about the migration; they needed to know what to click tomorrow morning.
Then the rollout, one group at a time. First my own machine. Then IT support, so they had seen the whole installation before a single user called. Then the IT department. Then the managers. Only then the rest of the staff. Each group tested the package and the guide for the next, larger group, and after each group there was a chance to fix something before it multiplied.
At the same time I tracked, machine by machine, where the new VPN had installed and where it had not. Every morning the list said whose desk IT support still had to visit, and nobody had to guess or ask around.
Communication started before the first installation and was repeated many times on the intranet and by email, to staff and to the external consultants alike: a change is coming, this is what it is, and this is what it means for you. Before their own group's turn, everyone got a more precise message: on these days the new VPN will start installing on your machine. At some point there will be a short VPN outage. Ordinary connections such as Teams keep working during it. When the outage is over, the new VPN is installed, and the attached guide shows how to use it.
Repetition made the outage expected. An expected outage is not a disruption but confirmation that things are going as promised.
The hundred external consultants were not on company machines, so nothing could be pushed to them. For them I made a separate distribution and a separate guide: a place to fetch the package from, and instructions for installing it themselves. Same package, different route.
A few people were on holiday or parental leave, and their machines were off during the deployment. For them I wrote IT support a simple procedure: connect remotely, copy the package, run the install, walk through the guide with the user. The exceptions were handled with the same package and the same guide, not improvised separately.
The result
The news came on Monday. On the Tuesday of the following week the last machine had been switched, a week before the old server was shut down.
320 users. Zero outages in business-critical systems.
Why it worked in seven days
Not because the technology was especially hard. Installing a VPN client is an installation like any other. The time was saved elsewhere.
Normally this is work for four or five people. One builds the package, another tests it, a third writes the guide, a fourth handles communication and a fifth fits the schedule. Between each of them is a handover, and every handover is a wait: a meeting, an email, "I'll look tomorrow". In a two-week project the handovers eat the time, not the doing.
Here it went like this. The packager finished the package and delivered it to the tester, who was the same person. The tester noticed that the installation cuts the VPN midway and told the writer of the guide, who already knew, having sat in the same chair. The person responsible for communication learned how the install behaves the moment it became clear, and the scheduler approved the installation order, IT support first and the rest of the staff last, without a meeting. Five roles, one chair, zero emails and Teams meetings between the roles.
That is why seven working days were enough for what a chain of several people would need a month for, and barely that. A fast change does not come from pushing harder but from removing the points where people wait. It needs someone who holds every part of the chain, and in IT projects that is rarer than it should be.