There’s something most IT leaders will admit privately but rarely say from a podium: We’ve gotten used to disruption. We plan for it, we staff for it, we build it into our roadmaps. Somewhere along the line we decided that periodic upheaval is what modernization looks like.
I did that, too — for years. Across three states and more than three decades in government IT, I approved my share of large infrastructure projects that promised a clean break from the past and delivered, along with the benefits, a stretch of months where everyone held their breath. I don’t think that pattern was ever as necessary as we told ourselves it was, and I’m confident it isn’t necessary now.
The Forklift We All Learned to Expect
The cycle is familiar enough that I can recite it from memory. The existing environment starts straining under demands nobody anticipated when it was purchased. Performance and capacity become recurring agenda items. Support timelines start closing in. A vendor arrives with a platform that will solve all of it, provided you’re willing to move everything onto it. A migration gets planned, usually on a timeline that assumed nothing would go wrong, and then the real work begins.
On paper those projects deliver a modern environment. What they also deliver is a long window of genuine operational risk: two infrastructures running side by side, data moving under deadline pressure, change windows that keep getting narrower and a persistent low-grade worry that something will break in a way nobody modeled.
Public sector teams pay more for this than most. They’re already short-staffed and over-committed. Every forklift project spends nights, weekends and a fair amount of political capital, and the bill doesn’t stop at the go-live date. The part that bothered me most as a CIO was the opportunity cost, because it never showed up in any project report. The security hardening that slipped a year. The automation work nobody got to. The service improvement an agency asked for and didn’t receive, because the four people who could have built it were consumed by a data migration.
We’ve treated that as the price of progress. I’d like us to question the premise.
Modernization Shouldn’t Feel Like an Event
At its best, modernization should be uneventful. It should sit alongside patching, monitoring, and capacity planning as routine work that competent teams do continuously without anyone outside IT noticing.
Getting there rests on a few ideas that sound modest and turn out to change quite a lot. Evolve in place rather than replacing in bulk. Treat infrastructure as a durable foundation instead of a disposable asset with a five-year clock on it. Decouple improvements in the underlying technology from the applications sitting on top of it, so that improving one doesn’t require disturbing the other.
Where that holds, an organization can add performance, capacity and capability without staging a disruptive event to do it. The technology improves behind the scenes. The applications keep running. The people using them never learn that anything happened, which is the whole point.
That’s what I mean by the last migration. Not that you never change anything again, but that you design your next transition so it’s the final time you have to endure the traditional high-risk cutover.
Continuity Is the Reason to Modernize Carefully
For mission-driven organizations, staying online impacts more than the job, but the entire community.
A state agency processing benefits, a university running student information systems, a city managing public safety workloads: In every one of those environments, downtime lands on a person who was counting on something. When we choose to re-platform a critical system, we’re making a bet that the long-term gain will justify the short-term exposure. That bet is sometimes worth making. My argument is that we’ve been making it far more often than the circumstances actually required.
A better approach starts from where we actually are. Services have to stay available while the infrastructure underneath them changes. Maintenance windows are getting shorter every year, not longer. Availability commitments and regulatory obligations leave very little room to absorb a bad weekend.
In practice that means favoring technologies that support non-disruptive upgrades and expansion, that can move or rebalance data and workloads transparently, and that allow changes to roll through an environment without cutting off users or the systems that depend on them. The test I’d apply is simple, and I’d apply it out loud in front of the vendor: Can we modernize this system in a way that almost nobody notices? If the answer involves a weekend and a rollback plan, keep looking.
The Part of the Cost That Lands on People
We talk about systems because systems are easier to talk about. The cost of every migration is carried by people.
Each refresh brings a wave of work that doesn’t automate well: discovering what’s actually in the environment, mapping dependencies nobody documented, assessing risk, writing and rewriting mitigation plans, scripting data moves, and sitting through change control meetings and stakeholder briefings that multiply as the date approaches. Then comes the compressed timeline and the long nights. Then, after go-live, a second wave nobody budgets for: troubleshooting, performance tuning and explaining to leadership why a promised benefit isn’t visible yet.
Run that cycle enough times and it wears teams down. I watched good people leave state government over it, and those are people who are very hard to replace at public sector salaries. It also pushes the survivors into a permanently reactive posture, which is the last thing you want from the group responsible for your security and your digital services.
A non-disruptive strategy addresses that directly. Fewer all-hands emergencies. More changes small enough to rehearse, roll back and refine. A shift away from depending on heroics and toward building systems that don’t demand them. I’d go further: If your next infrastructure decision doesn’t measurably reduce the operational load on your team, I’m not sure it qualifies as modernization at all.
Shrink the Blast Radius and the Risk Takes Care of Itself
Risk in IT projects isn’t only a function of technical difficulty. A great deal of it comes from scope and coupling.
Big-bang migrations are risky because of how much they bundle together. New hardware, new software and frequently a new operating model. Data moves and application cutovers crammed into the same window. Governance, security and process changes layered on top of all of it. When something goes wrong, and something generally does, you’re not troubleshooting a problem. You’re untangling a knot with a dozen plausible causes and a clock running.
The alternative is smaller and reversible. Make it easy to stand up new capability alongside what’s already running. Let the old and new environments coexist long enough to validate properly instead of validating under pressure. Design rollback paths you’d actually be willing to use. None of that eliminates complexity. What it does is refuse to concentrate the complexity into one brittle moment where everything has to go right at once.
That’s what the last migration means operationally. You stop staking the mission on a handful of infrequent, high-consequence events.
A Harder Set of Questions to Ask
If repeated rip-and-replace cycles are unsustainable, and I believe they are, then the criteria for the next infrastructure decision get clearer. Any serious candidate should be able to answer yes to a few things without hedging.
- Can it be refreshed and expanded without forcing a wholesale data migration every few years?
- Does it support non-disruptive updates, so service continuity survives the change?
- Will it reduce the operational burden on my team over its full life, and not just during the honeymoon in year one?
- Does its lifecycle model reward small iterative changes rather than large infrequent ones?
If the answers require a lot of qualification, what you’re buying is newer technology. That isn’t the same thing as modernizing.
Making This Migration the Last One
Every organization I talk to is being asked to do more with less, to innovate without putting reliability at risk and to protect both data and public trust in an environment that keeps getting more complicated. Continuing to schedule a disruptive overhaul every five to seven years doesn’t fit that reality. It barely fit the old one.
So I’d treat the last migration as a posture rather than a slogan. Design the next move so you never again need an all-or-nothing overhaul. Favor platforms that behave like a continuously improving utility instead of a series of disposable projects. And judge the result by what stops happening: fewer fire drills, fewer war rooms at two in the morning, fewer headlines about an outage.
Modernization ought to feel less like a storm and more like the tide. If your next project moves you toward that, it may be the most valuable migration you ever do, mostly because it should be the last one you have to.
For state, local, and education leaders thinking through what that looks like in practice, see additional resources on modernization, cyber resilience, and building a more predictable data foundation.
Jim Weaver is a former state CIO and nationally recognized public-sector technology leader with deep experience guiding government IT strategy, modernization, and cybersecurity initiatives. He served as Secretary and Chief Information Officer for the North Carolina Department of Information Technology, where he oversaw statewide IT strategy, procurement, cybersecurity, and broadband expansion. Prior to that, he served as CIO for the state of Washington, helping strengthen the state’s IT infrastructure and advance technology adoption across government. Jim also served as president of the National Association of State Chief Information Officers (NASCIO), contributing to IT policy and collaboration nationwide.
Leave a Reply
You must be logged in to post a comment.