When I was asked to own the IT for a new family entertainment centre — a National Geographic-branded venue under a large Kuwaiti group — the thing that made me happiest wasn't the brand or the budget. It was one sentence: there's nothing here yet. No decade-old domain controller nobody dares reboot. No spreadsheet that secretly runs the business. No "we've always done it this way." A blank sheet. In twenty years of IT you get a handful of those, and how you spend the first month decides how the next five years feel.
I built it on Microsoft Azure. Not because cloud is a religion, but because a new venue with a small on-site team and a need to scale for peak days is close to the ideal case for it — you don't want to be racking servers for a business whose load triples on a public holiday and halves the following Tuesday. Here's the order I did things in, and why the order is the whole point.
1. A blank sheet is rarer, and heavier, than it sounds
The temptation with greenfield is to start buying and building — spin up the servers, get something running, feel productive. I've learned to sit on my hands for a week first, because every early decision compounds. The domain design you rush in week one is the thing you're still working around in year four. So before a single resource existed, I wrote down what the venue actually needed the technology to do: sell tickets reliably on the busiest day of the year, keep guest and payment data safe, let a lean team administer it without a data-centre, and recover fast when — not if — something broke. Everything below falls out of those four sentences.
2. Start with identity, not servers
The single most important decision in a modern Azure build is one most people rush past: identity is your security perimeter now, not the network. In the old on-prem world I'd have started with Active Directory and a firewall. In the cloud, I started with Microsoft Entra ID and treated it as the control plane for everything — who exists, what they can reach, under what conditions.
That means getting the boring things right before anything fun: named accounts for everyone, no shared logins, multi-factor authentication as a non-negotiable default, conditional access policies that check where and how someone's signing in, and — the one people forget until it bites them — a break-glass account, stored properly, for the day your MFA provider has an outage and you're locked out of your own tenant. The 2026 landing-zone guidance from Microsoft says the same thing in more words: identity is the primary boundary, and role-based access, managed identities and privileged access management are what keep the environment from being quietly wide open. I built it that way because I'd seen the alternative — a flat estate where one compromised login is the whole game.
In a cloud estate, the question "is this secure?" reduces almost entirely to "is the identity layer done properly?" Get that wrong and nothing downstream can save you.
3. A landing zone before the first VM
The phrase "landing zone" sounds like consultant vocabulary, and it can be. Stripped of the jargon it means one honest thing: decide the structure your resources will live in before you start dropping resources into it. Subscriptions and resource groups organised so that production, test and management don't bleed into each other. Naming that a new engineer can read. Tagging so that in a year you can actually answer "what is this thing and what does it cost." Policy that stops someone spinning up an unencrypted, internet-facing database at 2am because it was convenient.
I didn't build the enterprise-scale version with dozens of subscriptions — this is a venue, not a bank, and over-engineering the structure would have been its own kind of failure. But the principle held: a small, clean landing zone first, workloads second. The half-day I spent on structure at the start has paid for itself many times over in audits I could actually answer and changes I could make without holding my breath.
4. Backup is a day-one decision, not a year-two regret
Everyone agrees backup matters. Almost nobody designs for it before they need it, and then a ransomware incident or a fat-fingered deletion turns it into the only thing that matters. I treated recovery as a founding requirement, not a bolt-on. That meant Veeam for the backup workload, with the piece that actually counts in 2026: immutability. A backup an attacker can encrypt or delete along with your live data isn't a backup — it's a second copy of the problem. Immutable, separated backups are the difference between a bad afternoon and a closed business.
The test I hold myself to isn't "do we have backups." It's "have I personally watched a restore work, recently, end to end." A backup you've never restored is a hope, not a control. I schedule the drill like I schedule patching, because the worst possible time to discover your restore is broken is the day you're depending on it.
5. The security baseline the venue runs on
With identity and recovery handled, the rest of the security baseline is about closing the doors attackers actually use. For this build that meant Proofpoint sitting in front of email — because email is still the front door for the overwhelming majority of incidents — and Bitdefender on the endpoints, with the whole thing feeding a coherent picture rather than five dashboards nobody watches. I also leaned on what the Microsoft stack gives you natively once identity is done well: conditional access, sign-in risk signals, and the security defaults that a small team can actually operate without a dedicated SOC.
The governing idea was proportionality. A family entertainment centre doesn't need a bank's security apparatus, and pretending otherwise would have burned budget and goodwill I needed elsewhere. But it absolutely needs the fundamentals done properly — MFA everywhere, email filtered, endpoints managed, backups immutable, logs somewhere you'd actually look. Most breaches I've studied didn't beat sophisticated defences. They walked through a missing fundamental.
6. What 2026 changes about a build like this
If I were starting the same venue today, one thing would be genuinely different, and it's worth naming because it's moving fast. Microsoft has spent this year turning Azure and Copilot into a single control plane for AI across the estate — governance, security and policy enforcement pushed into the identity layer, with security agents landing inside Defender, Entra, Intune and Purview. The upside is real: a small team gets capabilities that used to need a much bigger one. The catch is equally real, and it's the same lesson in new clothes. The moment you let an AI assistant reach across your data, your identity and permissions model stops being an IT hygiene issue and becomes the thing standing between "helpful" and "it just surfaced payroll to the summer intern."
Which is why I keep coming back to the same first move. Whether the estate is running virtual machines or AI agents, the build starts in the same place: get identity right, get recovery right, then let everything else stand on top. Design a system you can secure, audit and recover — the features are the easy part once that foundation holds. If you're planning a greenfield build and want a second pair of eyes on the foundations, get in touch.