Entrazure
What the advisory covers
The application portfolio, established once. Every application with a named owner, its business criticality, its support status with the vendor, where it runs, what it costs in hosting and licensing, and how often it actually changes. Most organizations hold three partial versions of this list in three departments, and none of them agree. The engagement produces one, and produces it in a format that can be kept current afterward.
The infrastructure underneath it. Operating system and database versions against their end of support dates, backup and recovery reality against the stated objectives, identity, and the network paths applications depend on. This is where the deadlines that drive the roadmap usually come from, and they are rarely the deadlines leadership is currently discussing.
A decision per application. Retire, rehost, replatform, refactor or retain. One choice per application, recorded with its reason, its cost and the condition that would change it.
A phased plan with a cost per phase. Phases grouped by dependency rather than by department, each with an entry condition, an exit condition, a cost and the risk it removes. The plan states what is bought with each phase, so a board can approve phase two without approving the whole program on faith.
The capacity question, answered honestly. Who executes each phase: your team, a delivery partner, or us. Where the plan assumes a skill your organization does not have, that is written in the plan rather than discovered in month four. Our architects work as a practice, so the reasoning behind every recommendation is documented and reviewable rather than resident in one person’s memory.
The five dispositions
Retire. The cheapest modernization there is. Applications with no users, applications duplicated by something else you already pay for, and applications kept alive for a report that three people read. Retirement candidates are identified with usage evidence and a named owner to sign off, because retiring an application on assumption is how you discover its one remaining critical user.
Rehost. Move it as it stands, into a governed subscription, with the operating system and database brought to a supported version. Fast, reversible and cheap to reason about, which is why it is the right answer far more often than the market admits. Rehosting also buys time to decide properly, and time is usually the scarce input.
Replatform. Keep the application, change what it runs on: a database to Azure SQL Managed Instance, a web tier to App Service, a batch job to Container Apps. Modest engineering effort, real reduction in what your team has to patch and operate.
Refactor. Change the application itself. This is the expensive option and it is justified by change rate, not by age. An application shipping frequently earns it, an application that has not changed in years does not, whatever it looks like from the outside. When refactoring is recommended, the case is made in application modernization terms and priced accordingly.
Retain. Leave it where it is, deliberately, with the reason written down and a review date attached. Hardware dependencies, latency constraints, vendor support boundaries and pending replacement projects are all legitimate reasons to retain. Azure Arc brings retained servers, SQL instances and clusters under the same policy, monitoring and update management as everything else, so retaining does not mean running two operating models forever.
How the engagement runs
Phase 1, inventory. Read-only access, discovery data rather than spreadsheets, contracts and license position, and interviews with the people who operate each system. No changes to production at any point.
Phase 2, dispositions. Working sessions per application group with the owners in the room. Each application leaves the session with a recorded decision or with a named blocker and a date. Blockers are usually ownership or vendor support, and both are cheaper to resolve here.
Phase 3, sequencing and cost. Phases assembled by dependency, priced, and ordered so the deadlines that actually bite are met first. The output includes the phases we recommended against, with the reason, because a plan that hides its rejected options cannot be challenged.
Phase 4, governance. The portfolio is handed over as a register that stays current, with a review cadence, an owner and the small set of fields that have to be maintained for it to remain worth anything. A portfolio nobody updates is a snapshot, and snapshots go stale within a quarter.
What you keep
- The application portfolio, with an owner, a cost and a change rate per application.
- A recorded disposition per application, with its reason and its reversal condition.
- The end of support calendar for operating systems, databases and vendor products.
- A phased plan with an entry condition, an exit condition and a cost per phase.
- The list of unowned applications, separated out, with the decision each one needs.
- A business case in board language: what each phase costs, and what it prevents.
Who this is for
Organizations of roughly 50 to 5,000 people carrying an estate that grew over a decade or more, with a mandate to modernize and no internal architecture function to shape it. Manufacturers with plant systems, public bodies with long-lived line-of-business applications, health services groups with clinical dependencies, and any organization that has absorbed an acquisition and inherited a second version of everything.
It works well immediately after a cloud strategy engagement, which settles the destination, and immediately before a migration, which executes against the dispositions this engagement records.
Who this is not for
If you already know exactly what is moving and when, and the disagreement is about execution rather than direction, buy the migration and skip the advisory.
If the mandate is to reduce cost this quarter, modernization is the wrong instrument. Cloud cost optimization acts faster and does not require a program.
If the real constraint is that nobody will fund the phases, the plan will be accurate and nothing will happen. That is a leadership question rather than an architecture one, and a fractional CIO engagement addresses it more directly than a report does.
Related
- Cloud strategy consulting, the decisions that set the destination.
- Application modernization, what replatforming and refactoring actually involve.
- Azure migration and VMware exit, the engagement that executes the dispositions.
- Managed Azure and FinOps, the operating model the estate lands in.
- All Azure services, the catalog each phase draws on.
Questions we get
We have no architects in house. Does that make this harder?
It is the normal starting condition, and it shapes the deliverable rather than the price. When there is no internal architecture function, the plan is written so it can be executed by an operations team plus a delivery partner, and the reasoning is written down in full instead of assumed. We also say plainly which phases require capability you do not currently hold.
Do we have to modernize everything?
No, and a plan that modernizes everything is a plan written to be sold rather than executed. Most portfolios resolve mainly into retire, rehost and retain, with a small set of applications where replatforming or refactoring genuinely pays back. Naming that small set accurately is the value of the engagement.
Who decides the disposition of each application?
You do, in a working session, with our recommendation and the reasoning in front of you. We bring the evidence: support status, change rate, hosting and license cost, dependencies, and the operational risk of leaving it alone. The decision is recorded with the name of the person who made it and the date.
What if an application has no owner?
That is a finding, not an obstacle. An application nobody owns is either a retirement candidate or an incident waiting for a trigger, and it is usually cheaper to establish that now than during a migration window. Unowned applications are listed separately so leadership sees the size of the problem.
How is this different from a migration plan?
A migration plan answers how things move. This answers whether they should, in what order, and what it costs against what it prevents. The two are sequenced: the disposition decisions here become the wave plan in a migration engagement, and several applications will be retired before anything moves.
Can you execute the plan as well?
Yes, and the plan is written so you do not have to use us. Phases carry named services, entry and exit conditions and a cost per phase, which is what a competent third party needs. Where we do deliver, the advisory and the build are quoted separately so each can be judged on its own merits.
Have a question about this work?
Three fields. An architect reads it and answers within one business day.