SERVICE SCOPE
What’s in scope.
01
Business and engineering constraints
Identify the application owner, intended outcome and the constraints on safer or faster change. Record security, performance, resilience and other requirements that must remain true after the work.
02
Architecture and dependency review
Inspect the runtime, code, data, identity, infrastructure and integrations. Compare the implications of retaining, retiring, replacing, rehosting, replatforming or refactoring the workload.
03
Platform and operating fit
Evaluate target options such as App Service, Container Apps, Azure Kubernetes Service or managed data and integration services against workload requirements and the team’s ability to operate them.
A decision package for the application owner.
Use a bounded proof to reduce uncertainty about the route before planning delivery.
✓
Current-state application map and constraint register.
✓
Route recommendation with rejected alternatives.
✓
Target architecture and security requirements at decision level.
✓
Experiment plan, delivery backlog and decision gates.
✓
TCO assumptions and unresolved evidence gaps.
When this review fits.
Use it when one application has a clear business or engineering constraint. Use the Azure Modernisation Map when several workloads and dependencies need a coordinated estate decision.
01
A focused question about one application
Use the sprint when a particular application is expensive to maintain, difficult to release or constrained by its platform. Define the business behaviour that must survive before examining the technical route. A runtime update, platform move and redesign solve different problems and carry different validation requirements.
Microsoft’s application-assessment guidance distinguishes hosting evidence from code-level evidence. The sprint should record whether conclusions come from infrastructure discovery, repository review or a bounded experiment, and make missing evidence visible. The name describes a focused engagement; its duration and engineering deliverables need confirmation for the actual application.
02
Bring the code and the people who understand its behaviour
Useful inputs include the repository, build instructions, runtime and dependency inventory, architecture notes and representative user journeys. Identify integration owners and any third-party components whose support constrains the target. If source access or a working test environment is unavailable, agree which questions can still be answered.
The customer’s application owner should approve the chosen business scenarios and acceptance criteria. The assessment output should separate findings, validated experiments and assumptions. Agree whether implementation-ready changes are included; a route recommendation or proof is not the same as a production release. The resulting backlog should name work required in the application, its hosting environment and its operating model.
03
Decisions the assessment should make visible
Decision
Evidence to examine
What to agree
Depth of review
Available code, build, hosting and integration evidence.
What is assessed directly and what remains an assumption.
Modernisation route
Business constraint, compatibility and operating complexity.
The justified target and alternatives rejected with reasons.
Next delivery step
Experiment results, unresolved risks and customer acceptance needs.
The engineering work and evidence required before production change.
BEFORE YOU DECIDE
Practical questions.
▸
Does modernisation require a rebuild?
▸
Is Kubernetes the default?
▸
Can Copilot assist?
▸
Does the sprint cover the entire application portfolio?
▸
What if the repository does not build?
▸
Will the proof be deployed to production?
▸
Who decides whether the proposed route is acceptable?
BUILD YOUR BUSINESS CASE
Use one application to test the next step.
The problem to solve.
A portfolio-wide modernisation estimate is difficult to trust before the team has tested the dependencies and delivery effort in a representative application.
What success should look like.
Use a bounded sprint to produce evidence about the architecture, engineering work and operational changes needed for the wider programme.
Bring these into the discussion.
A useful starting point for your team and the people approving the investment.
Useful reading for your proposal.
Evidence, examples and questions to take into the decision.
Insight
20 August 2026
Pilot design
Test the dependencies a hosting move exposes
A practical identity example for the sprint checklist.
Read the insight
Insight
25 August 2026
Application ownership
Bring runtime ownership into the scope
Define who will act on lifecycle changes after the sprint.
Read the insight
LET’S GROW.
Work through the next step with Braintree.
Bring a representative application and the decision the sprint must inform.
