Cloud Services

What Does an Assessment Need From You?

Design starts with an inventory of what is actually running, and the item that derails a cloud project is rarely the main application. It is the reporting database somebody restores by hand every quarter, the scheduled job on somebody's workstation, the fixed IP address an outside partner allowlisted, the license tied to a hostname. Those surface when someone walks the list of running things, not when someone reads an architecture diagram, which is why the inventory is a working session rather than a form to fill in.

The second input is access, and read-only is enough at this stage: viewer rights across the existing cloud accounts, subscriptions, or projects, plus the billing or cost export. Reading the accounts and the billing export together answers questions no workshop can, because it shows what is deployed and what each part costs rather than what the diagram says should be there. Where nothing is in the cloud yet, the equivalent is a hypervisor inventory and the last twelve months of invoices.

The third input is a person who can decide. Cloud design forces choices that cross team boundaries: which team owns a shared database, whether a legacy integration can finally be retired, how much downtime a cutover is allowed to take. Someone with the authority to answer those in the room, or on a short turnaround, moves the work faster than a full specification does. Four further specifics are worth gathering before the first design session, because they are what most often changes a design after it has been drawn:

• Recovery expectations stated as numbers, per application rather than for the estate as a whole: how much data loss is tolerable, and how long the system can be down.
• Runtime, framework, and database versions still in use, including anything past vendor support, since those constrain which managed services and machine images are usable targets at all.
• The maintenance windows you genuinely have, including any customer or contractual limit on when a system can be offline.
• Existing hosting, colocation, and support contracts with their notice periods and renewal dates, because those set the outer edge of any migration schedule.

Which Decisions Are Expensive to Reverse?

Some choices cost nothing on day one and a great deal in year two. Address space is the clearest. A virtual network numbered 10.0.0.0/16 because that was the default collides the first time you peer with an acquired company, a partner network, or your own office range. Choosing ranges deliberately out of RFC 1918 space and writing down which range is reserved for what costs almost nothing at the start, and afterward the only remedies are renumbering or another layer of address translation.

The second is region and availability zone layout, which is where a data residency obligation stops being a policy document and becomes a design constraint: moving a stateful workload to another region later is a data migration, not a configuration change. The third is the boundary between production and non-production. Separate accounts, subscriptions, or projects give you a blast radius the provider enforces, rather than one that depends on every policy in a shared account being written correctly forever. Splitting them later means moving resources between accounts, and not every resource type supports being moved.

None of those three are hard to get right when they are decided on purpose; they are expensive only when they are inherited from a default. The same is true of four smaller choices that otherwise get made by whoever creates the first resource, and that are worth settling before anyone does:

• Which directory is authoritative for human access, and whether cloud roles are granted through groups in that directory rather than to individual named accounts.
• Where DNS is hosted and who is allowed to change it, including whether the production zone is delegated separately from whatever test environments use.
• The database engine and version, since a managed service supports a narrower version range than a self-installed server and imposes an upgrade cadence you do not control.
• A naming and tagging convention enforced when a resource is created rather than applied afterward, since a policy check can reject an untagged resource at creation and retrofitted tags land inconsistently.

Lift and Shift, Replatform, or Rearchitect?

Moving an existing application is really three different jobs, and most real environments need a mix of all three. Lift and shift moves the machine roughly as it is: quickest to execute, and it carries the current operating system, patch state, and sizing along with it, so the first month's bill often compares badly with the hardware it replaced. Replatform keeps the application code but swaps components for managed equivalents, most often the database, the load balancer, and the object store; the work is in the differences, because a managed database engine restricts superuser rights, plugin sets, and file system access that a self-hosted install allowed.

Rearchitect changes the application itself, and it is the only one of the three that can change the shape of the cost rather than its level, because it is the only one that lets capacity follow demand. It is also the only one that requires the application team rather than just the infrastructure team, which is why it is scoped per component instead of per estate. A defensible pattern is to replatform the parts with a managed equivalent, lift and shift the parts nobody is going to touch, and rearchitect only what has a specific reason: a component that cannot scale, one that blocks releases, or one running on something no longer supported.

The predictable failure is the lift and shift that was presented internally as a first step. Once the machines are running and the project is declared finished, the pressure to take the second step disappears, and the estate keeps its old shape and gains a rental bill. If a plan depends on a later phase, name what triggers that phase, who owns it, and what budget it sits in before the first machine moves, because after the move nobody is asking.

What Has to Be True Before a Pipeline Helps?

A pipeline automates the release process you already have. If a release today is a person following a document, automation gives you a faster and more repeatable version of that same process, including the parts of it that were never right. The order that works is environments defined as code first, then build, then test, then deploy, because a pipeline that deploys into an environment nobody can rebuild has automated only the last and easiest step.

Deployment strategy is decided by the application, not by preference. Rolling, blue/green, and canary releases all run two versions of the code at once for some period. A database change that is not backward compatible with the previous version rules all of them out and leaves you with stop and replace. The way around that is expand and contract: add the new column, ship code that writes to both, backfill, and remove the old column in a later release, which turns one risky deployment into three dull ones.

Beyond tooling, a pipeline needs a build that produces the same artifact from the same commit on a clean machine, tests whose failure genuinely stops the release, and secrets that live in a managed secret store rather than in the repository. Each of those is a change in how the team works rather than a product you install. A pipeline missing any one of them still runs; it just automates a release you cannot reproduce, cannot verify, or cannot rotate credentials for.