Multi-year cloud transformations fail in predictable ways. The vision is sound, the business case is compelling, and the engineering talent is there. What breaks down is strategy, specifically, the failure to be ruthlessly selective about what gets rewritten, what gets maintained, and what gets left behind.
Mike Swafford, a senior engineering leader who led Microsoft’s transformation of Exchange Online from an on-premises box product into a fully cloud-based service spanning thousands of developers over multiple years, has navigated that complexity at a scale most organizations never approach. His approach to keeping transformations on track is built on one foundational discipline: strategic targeting. “You have to be very specific about what you’re trying to accomplish,” Swafford says. “You can accomplish big things by being very strategic about what you do.”
The Art of Strategic Restraint
The instinct in large-scale transformations is to pursue completeness. To rewrite everything, modernize everything, and arrive at a clean state. That instinct is what kills transformations midway. At Microsoft, the Exchange Online migration succeeded precisely because Swafford’s team resisted it. The strategy was to maintain strong boundaries between what was being rewritten and what was being kept functional, ensuring the product remained usable throughout. His own mailbox ran on the latest version of the product during the rewrite.
The team made deliberate bets about where to concentrate investment and was equally deliberate about what could be deprioritized. “Being very strategic about not saying we’re going to rewrite this all at once, but keeping the original code functional while we did rewrites,” Swafford says. The result was a transformation that moved continuously rather than stalling in the all-or-nothing trap that catches most programs of this scale.
The same philosophy produced over $1 billion in cumulative cost savings, not through a single initiative, but through annual chief financial officer (CFO)-driven targets that compounded over time. Swafford built a team specifically skilled at identifying diverse cost reduction opportunities: optimizing compute utilization, improving data center cooling efficiency, refining power distribution, and operating existing infrastructure at slightly higher temperatures to reduce operational cost.
When the Microsoft Dev Box VHD size was reduced by 50%, it followed the same diagnostic instinct. Developers were complaining about large image sizes. The team investigated, discovered the Dev Boxes contained components developers did not actually need, and redesigned the build process to generate only necessary artifacts. “If something smells wrong, dig a little deeper and develop a targeted engineering plan to address it,” Swafford says. The savings followed from the discipline of looking precisely at where cost was actually going rather than making broad assumptions.
AI Is Doing Both Things Simultaneously
The question most engineering leaders are wrestling with right now is whether AI makes the job easier or harder. Swafford’s answer is that it does both, and the leaders who only see the productivity upside are setting themselves up for a new category of operational problems. On the upside, teams can produce more code faster, add functionality at an accelerated pace, and implement security improvements that would previously have taken significantly longer.
The risk most leaders are underestimating is what Swafford describes as a potential dystopian outcome, in which developers spend the majority of their time reviewing and validating AI-generated code rather than building. The volume of output AI enables can outpace the validation capacity required to ensure that the output is sound.
His response to this is governance with teeth. Preferred AI tools installed as part of the standard developer environment, centralized marketplaces for curated plugins, skills, and Model Context Protocol tools, and formal evaluation processes for AI-generated outputs. “There’s really no way to do massive refactoring or rewrites without having a strong investment in how you validate things,” Swafford says.
The Disruption Risk Nobody Is Fully Accounting For
Looking five years ahead, Swafford’s most pointed observation concerns the scale of disruption. When code is cheap to produce, the competitive moat shifts entirely to the idea and to customer stickiness. Organizations that fail to innovate will face disruption not from small early-stage companies, but from well-resourced competitors who can now build at a speed that was previously impossible. “If you don’t innovate and someone else innovates, they’re going to move,” Swafford says.
The engineering leaders preparing for that reality now are rethinking team composition, skill requirements, and how AI-armed engineers can be redeployed to expand scope rather than simply maintain existing headcount against existing problems. A thousand AI-equipped engineers can accomplish more than a thousand engineers meaningfully without them. The leaders who recognize this are already asking different questions about where to point that capacity.
Follow Mike L. Swafford on LinkedIn for more insights on engineering leadership, cloud transformation, and building high-performance technical organizations.
