We had a critical gap in our delivery pipeline. Our repository had migrated to GitHub, but our build and deployment pipelines hadn't followed — we were still running production deployments through Bitbucket. Fixing that was top of the list.
We had a professional services quote on the table to do it. Well-scoped, fairly priced, from a partner who knows our environment well. We decided to try it ourselves with AI first, and it took a day.
This isn't a post about how we did it. It's about what it signals.
We made a deliberate investment in our infrastructure foundations. We adopted an Azure Landing Zone with a spoke-and-hub architecture. We moved to infrastructure-as-code through Terraform. We locked down our Key Vault and Storage Account access with IP-based network rules, and built consistent environment patterns across our spokes.
None of that felt glamorous at the time. It was the kind of work that doesn't impress anyone outside the engineering team, and is genuinely hard to justify in a quarterly plan when you have urgent features to ship. But it created something valuable, an environment with clear intent, consistent patterns, and a permissions model that was codified and documented.
That investment is what made the pipeline migration fast.
We used AI to read the existing Bitbucket pipeline. A single complex file containing multiple deployment jobs, environment-specific steps, and network access patterns. We iterated on a design with the AI. What were we actually trying to achieve? How did we expect deployments to evolve? What flexibility did we want to preserve?
From that we produced a set of reusable GitHub Actions workflows: _deploy-apps, _terraform-apply, build-solution, deploy-[spoke]. Each workflow uses instruction gates so deployments can target everything, or just specific components. More composable than what we had before, not just equivalent.
The old pipeline also carried a workaround we'd lived with for a while — dynamic IP whitelisting to handle unpredictable Bitbucket runner egress. Moving to GitHub's larger runners with a fixed IP range made it unnecessary — the firewall rules became permanent and the whole workaround disappeared. Simpler, faster, and meaningfully more secure.
Because our infrastructure was already codified, we could use AI to scope the work, and then port the old single Bitbucket pipeline file into a well-orchestrated set of GitHub Actions. That's the part worth paying attention to.
The quote we had received wasn't wrong. It reflected exactly what professional delivery costs and what it delivers — design documentation, peer review, stakeholder alignment, knowledge transfer, handover. That process exists for good reasons. It creates accountability and shared understanding that outlasts the engagement.
But the experience made us think carefully about where the real value sits. And it might not be in the implementation anymore. It's in the foundations.
A proper Landing Zone, a clean hub-and-spoke architecture, and a codified identity and permissions model is what made this possible. You can build it yourself, you can engage a partner to fast-track it, or some combination of both. That's not the point. The point is that having it is what changes the equation.
AI applied to a well-structured environment is a fundamentally different proposition to AI applied to a mess. The better your foundations, the more leverage AI can apply on top of them. That prior investment doesn't depreciate as AI gets better at implementation. It compounds. The gap between teams who have that foundation and teams who don't isn't narrowing. It's widening.
For in-house teams, the message is simple: the investment you made in boring infrastructure work is about to pay dividends you didn't plan for.
It's just one data point. But I thought it was a data point worth sharing.
Have you seen the same in your environment? Tweet us on X with #intutobuild and tag us @intutohq.
Authored by Aaron Leggett, Principal Product Architect at Intuto. Photo by RinaS.