Modernize applications without disrupting the business.
Lifting an application into the cloud unchanged usually makes it costlier, not better. We work out which applications repay real change, and which should be left alone.
Outcomes you can expect.
Portfolio assessment & strategy
We score each application on value, technical debt, change rate and return, then decide which repay real change, which to replatform, and which to leave exactly as they are.
Who it is for
- Teams told to move everything to the cloud who suspect that some of it should stay put.
- Organisations with a large estate and a modernization budget that covers only a few applications.
- Technology leaders who need a ranked list, with the reasoning, to defend to the board.
What you get
- Every application scored, with the reasoning shown
- A route for each: rehost, replatform, refactor, rebuild, replace or retain
- A dependency and database-coupling map for the candidates
- A sequenced roadmap with the first deliveries chosen
- An honest list of what to leave exactly as it is
What we do
Inventory the portfolio
We list every application with its owner, users, runtime, dependencies and licence terms, using discovery tooling and the people who know the systems.
Score each application
Business value, technical debt, change rate, risk and running cost, so the effort goes where it earns a return and not where the noise is.
Choose the route for each
Rehost, replatform, refactor, rebuild, replace or retain, with the reason written down and the cost of each route.
Read the code and the data
Static analysis, dependency graphs and database coupling show how tangled an application really is, which is rarely how it is described.
Sequence the work
We rank candidates, pick the first one or two to deliver, and write down what to leave alone and why.
Application portfolio assessment
A bounded look at which applications repay real change and which should be left alone, ending in a ranked list and a written route for each.
What is examined
- Which applications exist, who owns them, who uses them and what they depend on
- How much technical debt each carries, and how often it actually changes
- How tangled each is in code and in its database, found with analysis tools
- What each route would cost: rehost, replatform, refactor, rebuild, replace or retain
How it works
- 01 Scope. We agree which applications and questions are in, and who we need to talk to.
- 02 Discover. We inventory the portfolio with discovery tooling, and talk to the owners and users.
- 03 Assess. We score each application and read the code and database coupling for the candidates.
- 04 Report. We write up the ranking and the route for each, with the reasons, in plain language.
- 05 Review. We walk through the report with your team, answer questions and agree what happens next.
What you receive
- Every application scored, with the reasoning shown
- A route and a cost for each one
- A map of dependencies and database coupling for the candidates
- A readout session with your team
- If you want help, we can deliver the first applications, or hand the roadmap to your own team.
- If the answer is to leave most things alone, you keep a clear record of why.
Scope and timing are agreed on a call, before anything is committed.
Containers, decomposition & serverless
We containerize applications properly, split monoliths with the strangler fig pattern around real domain boundaries, and use serverless and managed services where they fit, and not where they do not.
Who it is for
- Teams with a monolith that is slow to change and frightening to release.
- Organisations that moved to containers and microservices and found the same coupling in smaller pieces.
- Engineering groups weighing serverless against containers for a new workload.
What you get
- Containers with hardened images, probes and a secure registry
- A domain map showing bounded contexts and where to cut
- The first slice live behind a gateway, with the old path still available
- Data split without a big-bang migration
- A written view on where serverless helps and where it does not
What we do
Containerize with care
Hardened, minimal or distroless images, health probes, twelve-factor configuration, secrets kept out of the image, and a signed, scanned registry such as ECR, ACR or Artifact Registry.
Find the real boundaries
Domain-driven design and event storming locate bounded contexts, so services follow the business and not the org chart or the old code layout.
Strangle, do not rewrite
An API gateway routes traffic between old and new behind an anti-corruption layer, with feature flags and parallel runs, so each slice goes live while the monolith keeps working.
Separate the data
We split shared tables with change data capture and the outbox pattern, and use sagas where a transaction crosses services.
Choose serverless honestly
Event-driven design on Lambda, Azure Functions or Cloud Run, with SQS or Pub/Sub, where load is spiky and state is light, and a plain container where cold starts or cost say otherwise.
Data platforms & integration
We build the data platform around your applications: lakehouse architecture, event streaming and batch pipelines, orchestration, data contracts and governance, so analytics does not depend on poking production.
Who it is for
- Teams whose reports run against the production database and slow it down.
- Organisations with a batch job nobody owns that everything downstream depends on.
- Businesses that want events and analytics without every team building its own pipeline.
What you get
- A data platform architecture with the reasons for it
- Event and batch pipelines running with schema management
- Tested, documented transformations with lineage
- Orchestration with an owner and an alert for every job
- Data contracts, access control and a catalogue
What we do
Choose the architecture
A lakehouse on open table formats such as Iceberg or Delta, or a warehouse such as BigQuery, Redshift or Synapse where that is simpler, with the trade-offs written down.
Move data in
Change data capture and Kafka for events, plus batch ingestion, with schemas managed so a change upstream does not silently break everything downstream.
Transform with tests
dbt models in layers, bronze to silver to gold, with tests, documentation and lineage, so numbers can be trusted and traced.
Orchestrate reliably
Airflow or a similar orchestrator with retries, alerting and backfills, and an owner for every job, including the 3am batch.
Govern the data
Data contracts between producers and consumers, access control, data quality checks and a catalogue, so people can find data and know whether to rely on it.
Ready to get started?
Book thirty minutes with our team for a clear view of scope and cost.