When you need it
Your important applications still run on servers that someone patches by hand, and every release is a manual job. Only a few people know how to deploy them, and each change feels risky.
What sets the quote
- 3 weeks: one application that needs no code changes to run in a container, connected to one existing data store, with one production cut-over window.
- 10 weeks: 3 to 10 services on one target platform, with up to 5 data stores and 3 cut-over windows.
- The runtime path sets the effort: .NET Framework on IIS runs in Windows containers without a port, while Linux containers first need a port to current .NET, sized per application.
- Moving a data store to a managed database adds to the quote, for example SQL Server on a VM to Amazon RDS for SQL Server, Azure SQL Managed Instance or Cloud SQL for SQL Server.
- Cut-over windows outside office hours, and extra rehearsals, add to the quote.
- Larger estates are quoted after sizing from a short application inventory you fill in.
What changes
- Your applications run in containers on a managed platform instead of hand-built servers.
- Releases go through a pipeline with tests and approvals, and any release can be rolled back.
- Deployments follow a runbook your whole team can use, not one person's memory.
- You can keep modernising the code step by step, without another platform move.
What you get
- Modernisation plan per application: move as it is, or change first, with the runtime path for each
- Container images for each application, with Windows containers where IIS is needed
- Target platform as code (Terraform by default) on Amazon ECS on AWS Fargate, Azure Container Apps or Cloud Run
- CI/CD pipeline with build, tests, image scanning and an approval gate, deploying without stored cloud keys
- Secrets moved out of configuration files into AWS Secrets Manager, Azure Key Vault or Google Cloud Secret Manager
- Logging, monitoring and a tested rollback path for every release
- A cut-over runbook per application, rehearsed before the production window
- Handover documentation and runbooks for your team
What we cover on each platform
| Area | AWS | Azure | Google Cloud |
|---|---|---|---|
| Runtime | Amazon ECS on AWS Fargate | Azure Container Apps | Cloud Run |
| .NET Framework on IIS | Windows containers, no port needed | Linux containers only, so apps are ported to current .NET first | Linux containers only, so apps are ported to current .NET first |
| Images and secrets | Amazon ECR, AWS Secrets Manager | Azure Container Registry, Azure Key Vault | Artifact Registry, Secret Manager |
| Managed databases | Amazon RDS, including SQL Server | Azure SQL Database or Azure SQL Managed Instance | Cloud SQL, including SQL Server |
| Releases and rollback | ECS deployment circuit breaker with automatic rollback | Revisions with traffic splitting | Revisions with traffic splitting |
| Logs and metrics | Amazon CloudWatch | Azure Monitor and Log Analytics | Cloud Logging and Cloud Monitoring |
For Rayna Tours we moved legacy .NET and IIS applications into Windows containers on Amazon ECS, with CI/CD.
Not included
- Rewriting applications or adding features (quoted separately)
- Desktop applications (containers run server workloads only)
- Data stores and data migrations beyond those agreed in the quote
- Software licences and cloud running costs, which your cloud provider bills to you
- Penetration testing (we can refer you to a certified partner)
- Day-to-day operations after handover (available as a managed cloud platform or application support, with optional 24/7 on-call)
What we need from you
- Source code, build scripts and the current server and IIS configuration for each application.
- An owner for each application, who tests the move, approves the cut-over and agrees its window.
- AWS: AdministratorAccess through IAM Identity Center in the target accounts during the build.
- Azure: Contributor and Role Based Access Control Administrator on the target subscriptions or resource groups during the build.
- Google Cloud: the Owner role on the target projects during the build.
How it works
Free 30-minute call and a short application inventory, then a written fixed quote.
A senior architect reviews each application and decides what moves as it is and what changes first.
One application is containerised end to end, with its pipeline, as the pattern for the rest.
The rest move in short iterations, each with a rehearsed cut-over and a tested rollback. Vetted specialists join when the scope needs them.
Handover of the platform, pipelines and runbooks to your team.
At a glance
- Duration
- 3–10 weeks
- Price
- Fixed quote after a free 30-minute call
- Delivered by
- Our lead architect and a cloud engineer
Related work
Rayna Tours and TechnoHeaven
From one legacy account to a governed multi-account AWS platform
A multi-account AWS foundation for a travel group's twenty or so services, with guardrails, keyless pipelines and a temporary environment for every pull request, all defined in Terraform.
- 8
- AWS accounts in one organisation
- 40+
- Terraform repositories
Related services
Product and architecture discovery
A discovery of 1–2 weeks that turns a product idea into a first-release scope, an architecture, a build estimate and a delivery plan, before you commit budget to the build.
Cloud-native web app or MVP
A web app or MVP with its API, built in your own AWS, Azure or Google Cloud environment in 4 to 12 weeks, with infrastructure as code, CI/CD and security gates from the first commit.
API and integration platform
Tested integrations with your suppliers, partners and payment providers that handle timeouts, retries and duplicate messages, so one slow partner cannot stall your product. Built in 2 to 8 weeks.