Cloud and Azure solutions

Two things make cloud programmes go wrong, and neither is technical. The first is moving a system unchanged and being surprised by the invoice. The second is discovering, during an incident, that the backup was never restorable. We size each workload on its merits — some should be rebuilt, some should be moved as they are, and some should stay where they are — and we test the recovery path before we need it. Azure is where most of our work lands, because most of our clients already have the tenancy, the identity and the licence agreement.

• 01

  A per-workload decision rather than a programme-wide one, with the cost and effort of each option written down before you commit.

• 02

  Infrastructure defined as code from the first environment, so staging and production are the same shape and a rebuild is a pipeline run rather than an archaeology exercise.

• 03

  A restore that has actually been performed. We rehearse recovery to a stated objective and give you the timing evidence, because an untested backup is a belief.

• 04

  Cost visible per workload and per environment from week one, with budget alerts and a monthly review. Trellis Financial’s bill fell 38% in the first quarter, mostly from right-sizing and switching non-production off overnight.

• 05

  Identity, network and data-residency constraints settled at the start. Retrofitting them is the expensive version, and in regulated sectors it is sometimes the impossible version.

1. 01

   Estate and cost survey

   Two to three weeks. Every application, its dependencies, its data volumes and what it currently costs to run — including the licences and the people. That baseline is what any later saving is measured against.

2. 02

   Landing zone

   Subscriptions, network topology, identity, policy and logging built as code before any workload moves. Doing this after the first migration means doing the first migration twice.

3. 03

   Workload-by-workload move

   Each workload gets its own decision — rehost, re-platform, rebuild or leave — and its own cutover with a rollback. They move one at a time, and each one is stable before the next begins.

4. 04

   Resilience and recovery

   Backup policy, replication, and a documented recovery objective per workload — then an actual restore drill against it, timed, with the result recorded.

5. 05

   Cost and operations handover

   Tagging, budgets, alerts and a monthly cost review your finance team can read, plus the runbooks for whoever operates the platform afterwards.

• Infrastructure as code — Bicep or Terraform — covering every environment, in your repository.
• Landing zone with identity, network, policy and centralised logging configured.
• Per-workload migration decision record, with the cost and risk behind each choice.
• Backup and disaster recovery plan, plus the dated evidence of a completed restore drill.
• Cost baseline and post-migration comparison, broken down by workload and environment.
• Operations runbooks and an on-call handover pack.

• 01Will moving to the cloud reduce our costs?

  Not by itself — a lift-and-shift usually costs more than the servers it replaced. Savings come from right-sizing, switching non-production environments off outside working hours, moving to managed services that remove operational effort, and retiring what turns out to be unused. We show the modelled cost for each option before you commit, and the actual cost afterwards.

• 02Do you work with AWS or Google Cloud?

  We do, and we have. Azure is where the depth of this team is and where most of our clients already are, so it is our default recommendation when there is no existing commitment. If you are already on another provider, the right answer is almost always to stay and get good at it rather than to fund a migration between clouds.

• 03How do we know our backups actually work?

  Because we restore from them in front of you and time it. Every workload gets a stated recovery point and recovery time objective, and the drill either meets those numbers or the plan changes until it does. The result is dated, so you know how stale the evidence is.

• OPS

  DevOps and IT infrastructure

  Pipelines, environments, deployment and monitoring — so releasing is routine rather than an event.

  /services/devops-and-infrastructure
• NET

  .NET development

  ASP.NET Core, C# and the Microsoft server stack — our deepest bench, and the default for systems that have to last.

  /services/dotnet-development
• SEC

  Cybersecurity

  Application and website security, access control and data protection — assessed, fixed, and then kept fixed.

  /services/cybersecurity