01 / 06
Migration assessment
Component-by-component analysis of what to move, what to re-platform, what to rewrite, and what to retire, with the cost and risk of each stated rather than assumed.
SERVICE · CLOUD
Cloud & Modernization
Cloud migration goes wrong in two directions: lifting a system unchanged and paying more for the privilege, or rearchitecting everything at once and discovering the schedule was fiction. We work between those, moving components in an order determined by cost and risk, and changing only what the move actually requires.
THE PROBLEM
The cloud bill went up and nobody can say which service caused it.
The common outcome of a hurried migration is a system that runs in a data centre somebody else owns, at a higher monthly cost, with the same operational problems and a new set of ones nobody has experience with. Instances sized for a peak that happens twice a year run continuously. Storage tiers were never revisited. Data transfer between zones appears on the bill without appearing in any diagram. Meanwhile the deployment process did not improve, because the deployment process was never part of the migration. The cost is real but the cause is diffuse, which is why it rarely gets addressed until someone is asked to explain it.
Signals you might recognize
The cloud bill is growing faster than usage, and the attribution is unclear.
Infrastructure is configured through a console, so nobody can reproduce an environment.
Scaling means asking somebody to resize an instance.
A migration was started, partly completed, and quietly stopped.
WHAT WE DELIVER
What this actually includes.
Concrete engineering capabilities deployed as part of this service practice.
02 / 06
Re-platforming
Moving to managed databases, queues, object storage, and identity where the managed version is genuinely cheaper to operate, and keeping what you run yourself where it is not.
03 / 06
Containerization
One definition of the runtime so local, staging, and production stop disagreeing. Kubernetes only where the workload justifies operating it — it is a cost, and we say so before adding it.
04 / 06
Infrastructure as code
Environments defined in version control and applied through a pipeline, so a change is reviewable and an environment is reproducible rather than remembered.
05 / 06
Delivery pipelines
Automated build, test, and deployment with environment promotion and a rollback that has been used rather than documented. This is usually where the operational saving actually comes from.
06 / 06
Cost and observability work
Tagging and attribution so spend maps to services and teams, right-sizing against measured usage, and monitoring that reports on the symptoms users notice.
HOW WE WORK
How we approach Cloud & Modernization.
Milestone-driven delivery, so integration problems surface in week two rather than in week ten.
01
Inventory and attribute
What runs, what it costs, what depends on it, and what its actual utilisation looks like. Migration decisions made without utilisation data reproduce the current sizing in a more expensive place.
Stage 01 activities
- Component inventory with dependency mapping
- Current cost attribution, including the parts nobody has looked at
- Utilisation measurement over a representative period
- Data gravity and residency constraints identified early
02
Decide per component
Retire, retain, re-host, re-platform, or rebuild — chosen per component against cost, risk, and how often it changes. Applying one strategy to a whole estate is what produces both of the classic failures.
Stage 02 activities
- A disposition decision per component with stated reasoning
- Sequencing by risk and value, cheapest wins first
- Target cost model built before commitment
- The list of what will deliberately not move
03
Build the target ground floor
Networking, identity, secrets, logging, and the deployment pipeline exist and are tested before the first workload arrives. Migrating into an environment that is still being invented is how a schedule becomes fiction.
Stage 03 activities
- Network, identity, and secret management defined in code
- Centralised logging and metrics before the first workload
- Deployment pipeline with environment promotion
- A non-production environment that genuinely matches production
04
Move in slices, with a way back
One component at a time, running in parallel where possible, with traffic moved gradually and a rollback that is a routing change. The system stays live throughout; there is no weekend where it is neither here nor there.
Stage 04 activities
- Parallel running with traffic shifted incrementally
- Data synchronisation and cutover rehearsed before the real one
- Per-slice monitoring and an agreed rollback trigger
- Decommissioning only after a defined quiet period
05
Right-size against reality
After a few weeks of real load, resize against measured usage rather than the pre-migration guess, review storage tiers, and set attribution so the next cost question has an answer.
Stage 05 activities
- Right-sizing against measured rather than estimated load
- Storage tiering and retention policy review
- Tagging so spend attributes to services and teams
- Budget alerts on the components that can grow unnoticed
TECHNOLOGY DEPTH
Technologies behind Cloud & Modernization.
The libraries, runtimes, and services we standardise on for this work, and keep patched.
Backend
- .NET
- Node.js
- Python
Data
- PostgreSQL
- Redis
Cloud
- Azure
- AWS
- Docker
- Kubernetes
- Vercel
DELIVERABLES & OUTCOMES
What you receive, and what actually changes.
We measure success by durable working software in your possession, not presentation slides.
What you get
An assessment with a disposition decision and cost estimate per component
Infrastructure defined in version control and applied through a pipeline
Container images and a runtime definition shared across environments
Automated deployment with environment promotion and a tested rollback
Centralised logging, metrics, and alerting across the estate
Cost attribution by service and team, with budget alerts
What changes
A migration that runs during business hours, one component at a time
A cloud bill that attributes to services, so a cost question has an answer
Environments reproducible from version control rather than from memory
Deployment and rollback as routine operations instead of scheduled events
QUESTIONS & ANSWERS
Questions about Cloud & Modernization.
Direct answers to common technical and engagement questions.
Usually whichever your organisation already has identity, contracts, and skills in — that is worth more than any feature comparison. Azure tends to be the shorter path for a Microsoft-centred estate. Where there is no incumbent, we will make a recommendation based on the specific managed services the workload needs.
Probably not at first. It solves real problems at a scale most systems have not reached, and it is a platform you then have to operate. Container services with managed orchestration cover a large majority of workloads at a fraction of the operational cost. We will tell you when the trade genuinely tips.
Sometimes, and it depends on what you are moving from. A lift with no re-platforming and no right-sizing usually costs more. The saving generally comes from retiring components, moving to managed services that replace operational effort, and sizing against measured load. We build the target cost model during the assessment so this is a number you see before committing, not after.
It stays, and we connect to it. Data residency, a licensing constraint, or a dependency on specific hardware are all legitimate reasons not to move something. A hybrid arrangement with a clear boundary is a reasonable end state, not a failed migration.
Yes. The first step is an inventory of what has actually moved versus what was planned, because those two lists usually differ. From there it is the same sequencing work, with the advantage that some of the ground floor already exists.
Have something ambitious to build?
Tell us what you're working on. We'll tell you honestly whether we're the right team for it.