Case study 01 · Continuity
Six days
A university. Thirteen thousand students, faculty and staff. A campus-based institution with campus-based systems, being told the campus would close.
- 6 days
- 13,000 users
- 0 disruption to teaching
- 0 security incidents
What had to be true
Remote access architecture that could carry the whole institution without opening it to the internet. Security controls that held under load and under a threat environment that got noticeably worse that month. Faculty — several hundred of them, with every level of technical confidence from expert to reluctant — able to teach on platforms most of them had never opened.
Not one of those is a technical problem on its own. Together, in six days, they are.
The sequence
Day 0
The instruction
It came on a Sunday. The question wasn't whether we could move the institution online — it was whether we could do it before the term collapsed.
First
Access architecture
Remote access that could carry the whole institution without opening it to the internet. Nothing else could be tested until this existed.
Designed in
Security controls
Controls that held under load and under a threat environment that got noticeably worse that month — built in, because there would be no window to add them later.
From day 2
Faculty enablement, in parallel
Several hundred faculty, every level of confidence from expert to reluctant. The platform being ready and the people being ready are two different projects.
Day 6
Fully remote operations
No interruption to teaching. No security incident during the transition. The institution then ran remotely for two years on that architecture.
What we did
We sequenced by dependency rather than by urgency, which is a harder discipline than it sounds when everyone is urgent. Access architecture first, because nothing else could be tested without it. Security controls designed in rather than added after, because there would be no window to add them later. Faculty enablement running in parallel from day two, not queued behind the infrastructure — because the platform being ready and the people being ready are two different projects, and only one of them can be compressed.
I had a twenty-person department and three managers. What made it work was not heroics. It was that the estate was documented, the architecture was already understood, and the decisions could be made quickly because the groundwork had been laid over years when nothing was on fire.
Where it landed
Six days from instruction to fully remote operations. No interruption to teaching. No security incident during the transition.
The university gave me its Outstanding Performance Award that year. The part I'd point to instead: the institution ran remotely for the next two years on the architecture built in that week.
What it taught
Continuity planning is worth exactly what you invested in it before the day you needed it.
We moved in six days because of work done in the preceding six years, not the preceding six days.
Compress infrastructure, not people.
Systems can be stood up fast. Human readiness cannot, and treating it as a downstream task is how technically successful transitions fail.
Documented estates move quickly.
Undocumented ones argue first.
If your continuity plan has never been tested, it isn't a plan.