Enterprise Application Discovery Before a Rebuild

Enterprise Application Discovery Before a Rebuild: What Has to Be True Before You Scope the Work?

By Michael Branson | August 24, 2026

Quick answer. Enterprise application discovery before a rebuild produces four artifacts: a function and data inventory, a recovered business-rule register, an integration and user map, and written success criteria. Those same four artifacts are also the evidence behind the choice between rebuild, replace, retire, and keep.

An application that carries a revenue-bearing process is failing or aging out, the person who wrote it has left, and the documentation that survives describes the system as it was planned, not as it runs. Somebody asks what a rebuild would cost. The honest answer at that moment is that nobody knows yet, because what the application does has not been written down since the year it was written, and the distance between those two states is where rebuild budgets are lost. Discovery is the work that closes it. Discovery is not a strategy phase and not a workshop with sticky notes: it is an evidence-gathering exercise with a defined output, and that output is what a scope, an estimate, and a defensible go-or-no-go decision are built from.

What Discovery Has to Produce Before a Rebuild Is Scoped

Discovery earns its budget by producing artifacts other people can act on. Four of them carry the weight.

The function and data inventory answers what the application does and what it stores: screens, reports, batch routines, scheduled tasks, tables, and the fields that turn out to hold two different meanings depending on who typed into them. The business-rule register answers why the application behaves as it does, recording the calculations, thresholds, approval conditions, and exceptions that live in code, in queries, and in the heads of the people who work around them. The integration and user map answers what would break: the systems that read from or write to the application, the file drops nobody owns, the reports that quietly depend on a database view, and the roles whose daily work runs through the screens. The success criteria answer what “done” means in terms someone will sign: the processes the new system has to carry, the reconciliation that has to balance, and the conditions under which the old system is switched off.

Two of those artifacts are counted and two are agreed: the inventory and the map are the counted pair, the register and the criteria the agreed pair. That distinction matters at estimating time. A rebuild estimate built on the counted pair alone is arithmetic on an incomplete list. An estimate that also carries the recovered rules and the written criteria is defensible line by line, which is what a finance committee is asking for when it asks why the number is what it is.

The Inventory: Functions, Data, Integrations, and the People Who Use Them

Inventory work is unglamorous, and it is where surprises are cheapest. The table below breaks the four artifacts into the working lists discovery actually builds: functions and data are listed separately, so are integrations and users, and the business-rule register stays whole. Each row names a list, the content it lists, and the test that closes it.

The reason to write the tests down beside the artifacts is that inventories are easy to declare finished. A list of twelve screens looks complete until the accounts team mentions the quarter-end routine that one person runs. Microsoft’s own tooling makes the same point at infrastructure altitude: What is Azure Migrate? describes a free service whose first listed job is to identify your inventory of workloads, before any assessment or move is planned, and the same page notes that partner tools can charge for their own services. Nothing in the Microsoft tooling cited here produces the application-level equivalent, which is why the discipline has to come from the method.

One caution about the user and role map. It is the artifact skipped first and the one that produces the most expensive late findings, because the people who use a legacy application have spent years building workarounds around its limits. Those workarounds are load-bearing. A rebuild that implements the system as designed, instead of the system as operated, ships a product that is technically correct and operationally rejected.

Business-Rule Archaeology: Recovering the Rules Nobody Wrote Down

This is the part buyers underestimate, and it decides whether the estimate holds. The rules that govern a long-lived application sit in four places, and each place needs a different technique.

In the code. Stored procedures, form event handlers, macros, and the validation that fires on save. Reading it is slow, and it is a first-hand record of what the system executes rather than what somebody remembers, with the limit that the code in the repository is not always the code in production. Budget for a senior engineer reading code that has gone unmaintained, written in a language whose idioms have moved on.

In the data. The database retains the outcome of every rule that wrote to it, which is a subset of the rules that ran: a rule that only rejected a transaction, ran in another system, or wrote to logs that have since expired leaves no row behind. Distributions, gaps, and values that appear only under particular conditions expose logic the code no longer contains, including rules removed years ago whose historical rows still have to be interpreted by the new system.

In the people. Interviews find intent: why a threshold is set where it is, which exceptions are policy and which are habit, and which of the “rules” are one person’s preference that survived because nobody challenged it. Interviews alone are unreliable, which is why each rule recovered this way is checked against real cases before it enters the register.

In the workarounds. The spreadsheet that sits beside the application, the approval sent by email instead of through the screen, the report someone rebuilds by hand every Monday. Each one is a rule the system failed to carry, and each is a requirement candidate for whatever replaces it, tested the way an interview is: against real cases, and against whether the policy behind it still stands.

The four sources disagree, and the register needs a rule for that case. Code and data outrank memory on the system’s actual behavior: where an interview contradicts what the code executes and the data shows, the register records the executed behavior and carries the remembered version beside it as an open question for the business owner to rule on. Where the code and the data disagree with each other, the data states what happened and the code is read again for the branch that produced it. Where no branch in the running code produces it, the row goes to the risk list unresolved, because manual corrections, imports, and retired versions all leave data the running code cannot account for.

Tooling assists at the edges, not at the center. Microsoft’s Dependency analysis in Azure Migrate identifies dependencies between discovered servers running in VMware, Hyper-V, physical servers, or other public clouds. Microsoft’s documentation puts that environment list under the agentless option. The agent-based option is supported only in the classic view, and Microsoft’s documentation states that new servers can no longer be onboarded for it and that the classic view is scheduled for deprecation by the end of 2026. Dependency analysis returns server-to-server traffic observed as network connections on the servers where collection is switched on, which answers what talked to what while it was watching. It does not answer why a discount is capped at one value for one customer class. Business rules are recovered by people reading code, querying data, and interviewing users; a dependency map is not a rule register.

If rule recovery on your application is the part you are least sure about, that is the conversation worth having before a scope is signed, not after it. Bring whatever documentation exists and the name of the person who knows the system best. Talk to a senior architect. The conversation is about how deep the archaeology runs on your application, and one honest ending is that your own team is best placed to do it.

Data Migration Reality: What the Old Database Holds and What It Owes

A rebuild proposal contains a line for data migration, and it is the line priced as a transfer when it is an archaeology exercise of its own. Three questions decide the number.

What does the data mean? Field-level meaning drifts over a system’s life. A status column with six documented values holds eleven in production. A free-text field becomes the place three departments record three different things. Reconstructing meaning is discovery work, not migration work, and doing it during a migration is how cutover dates move.

What is the quality? Key integrity, duplicates, orphaned rows, and dates that predate the organization. The measurement is cheap: counts, key checks, and profiling queries against a copy. The decision it feeds is not cheap, because somebody has to rule on which records are corrected, which are migrated as they stand with their defects recorded, and which stay behind in an archive.

What does the data owe? Retention obligations, audit history, and the reports that regulators or auditors expect to still run when the application is gone. A rebuild that carries the live records and leaves the history behind creates a compliance question at the moment the old system is switched off, and answering it then costs more than answering it now.

The output of the data thread is the data statement: a written record of what moves, what is corrected, what is archived, and what is deliberately abandoned, with a named person signing each category. That statement is a scope boundary, and scope boundaries are what stop an estimate drifting.

Why Rebuild Projects Blow Their Scope

Rebuild overruns are not mysterious, and they are not mostly a technology problem. Four causes recur, and discovery addresses each one directly. They are not the whole account: governance, procurement, and funding produce delays discovery does not touch.

Rules found late. A rule discovered during discovery is a requirement. The same rule discovered during user acceptance testing is a change against a scope already signed, and under a fixed-scope contract that means a new price against a schedule already committed. The cost difference between those two moments is the entire argument for discovery.

Integrations counted as one thing. “It talks to the ERP” is not an integration. It is a set of interfaces, each with a format, a schedule, a failure mode, and an owner, and the ones that cross a team boundary carry a testing partner with their own release calendar. Counting the interfaces individually, with owners named, is what turns that line item into an estimate.

Data cleanup treated as a task. When profiling is deferred until migration, cleanup arrives as an unplanned project inside a planned one, at the point of maximum schedule pressure.

The undocumented operating model. The workarounds again: the process as run differs from the process as documented, and the gap surfaces when real users meet the new system. This cause produces the bitterest rebuild stories, because the software works and the business says it is wrong.

Each is cheaper to find while the scope is still open than after it is fixed, and that asymmetry is the case for funding discovery as its own piece of work with its own output, instead of absorbing it into the opening of a build.

There is a commercial reason for the same separation: a discovery output you own can go to more than one delivery partner, or to your own team, and come back as comparable numbers. If what your discovery has to cover is the open question, Talk to a senior architect. An honest ending is on the table from the start, including the ending where your existing documentation is already good enough and the rebuild can be scoped without a discovery engagement at all.

The Decision Discovery Feeds: Rebuild, Replace, Retire, or Keep

Discovery is not a commitment to rebuild. It is the evidence that makes the decision defensible, and the decision has more than two options.

Microsoft’s Cloud Adoption Framework puts the sequence in one sentence: Select your cloud migration strategies opens by stating that with a clear inventory and understanding of your workloads, your cloud adoption plan must determine what to do with each workload in the cloud, and the page states that each workload can be Retired, Retained, Rehosted, Replatformed, Refactored, Rearchitected, Rebuilt, or Replaced. The inventory comes first and the choice comes second. The mechanics of choosing between those paths for a given application are a topic of their own and are not re-taught on this page.

What discovery contributes to that choice is specific. The rule register shows how much of the application’s value is bespoke logic, which is what any packaged replacement has to be tested against. The integration map shows what a retirement would strand. The user map shows whether the pain is the software or the process around it. The data statement shows what any of the paths would owe.

When two of those readings point at different paths, the choice is not discovery’s to make. The discovery output records the disagreement, the evidence on each side, and what it would cost to resolve, and the people who own the process decide with that in front of them.

At estate altitude, where the question is which of many systems to touch and in what order, the live guide How Regulated Enterprises Decide Whether to Upgrade, Replace, or Keep Their Systems covers that decision across a Microsoft estate. Where the application has lost the developer who built it and the open call is whether to rewrite the code, maintain it, or replace it, When to Rewrite Legacy Code After the Developer Leaves sets out that call and the criteria behind it. Discovery produces the evidence; the decision is taken on that page. This page stays at the altitude of one application that is already a rebuild candidate.

What the Discovery Output Looks Like, and Who Signs It

An estimate is defensible when a stranger can read the document behind it and trace every line of the number to a recorded fact or a stated assumption. That is the standard the output is built to.

The document set is the four artifacts, plus the records that make them usable: the data statement, a written statement of what was NOT examined, and a risk list carrying the items discovery could not resolve, each with its likely effect on scope. The unresolved list is the most useful page in the pack, because it is what an estimate’s contingency is priced against, and a discovery report that lists no unresolved items is one to read again for what it did not reach.

Sign-off is where discovery becomes binding, and it needs more than one signature. The business owner signs the function inventory, the user and role map, the rule register, and the success criteria, attesting that the system as described is the system as operated. The data owner signs the data statement, including what is deliberately abandoned. The integration owners each sign for their own interface. IT signs the data inventory, the integration inventory, and the risk list. What each signature means belongs in writing on the page above it, because “reviewed” and “attested” are different acts and only one of them holds up later.

Success criteria deserve their own paragraph, because vague criteria are how a successful build becomes a disputed one. Good criteria name the processes the new system carries end to end, the reconciliation that has to balance against the old system, the performance the busiest role needs at the busiest hour, and the conditions for switching the old system off. Microsoft publishes assessment-shaped criteria for cloud workloads: What is the Azure Well-Architected Framework? states that its workload guidance includes an assessment for evaluating readiness in production. Borrowing that shape is reasonable; borrowing it as a substitute for criteria written against your own processes is not.

How i3solutions Runs Discovery Before a Rebuild

i3solutions has been a Microsoft partner since 1997, and the discovery described here is run as engineering, not as a study. Engineers read the code, query the data, and sit with the people who run the process. Delivery is senior and US-based.

The limit on this page’s claims is worth stating plainly. What Microsoft’s tooling does is cited to Microsoft’s documentation above; what the method adds is judgment about where to look, when a rule is proven, and what belongs on the risk list. Dependency mapping and business-rule recovery are different products, and a tool sold as the second is worth testing against a rule it was never shown.

When This Is Not the Work You Need

Some readers should route elsewhere, and it is cheaper to say so here.

If the destination is a Power Platform build rather than a custom rebuild, discovery is a different exercise: process truth, data model fit for Dataverse, delegation limits, licensing, and post-launch ownership drive that work, and rule archaeology is only part of it. If your application is a Microsoft Access database that has already failed and is taking a revenue-bearing process down with it, stabilization comes before discovery, and Replace Microsoft Access: Stabilize the Failing App, Then Decide walks that order. If the question in the room is the price and not the scope, How Much Does It Cost to Rebuild a Microsoft Access Application as a Web App? sets out the drivers that move an Access rebuild number. If the application is small enough that one person knows it end to end and can write the rules down without help, a discovery engagement is overhead: have them write it down, then get the estimate. And if the real question is which of thirty systems to touch first, that is estate-level analysis, not application-level discovery.

What is left is the case this page was written for: one application that matters, a rebuild that looks likely, and nobody able to say with confidence what the thing actually does. The four artifacts are the answer to that, the archaeology is the slow part, and the sign-off is what makes the estimate hold. Bring whatever documentation survives and the names of the people who work around the system every day. Talk to a senior architect. The conversation is about what your discovery has to cover, and its honest endings include your team running it, or a rebuild being the wrong path for this application. Both are useful answers, and the Custom Application Development Services for Enterprise Performance practice is where the build work sits if the answer turns out to be yes.

Frequently Asked Questions

What discovery should precede rebuilding a legacy application?

Four artifacts. An inventory of functions and data recording screens, reports, batch routines, tables, and field-level meanings. A business-rule register recording calculations, thresholds, approval conditions, and exceptions, each traced to the code, the data, the named person, or the workaround it came from. A map of integrations and users recording what reads from and writes to the application and which roles depend on it, with each interface confirmed by an owner on the other side. And written success criteria naming the processes the replacement carries end to end, the reconciliation that must balance, and the conditions for switching the old system off.

How do we extract business rules from an undocumented system?

From four sources, using a different technique on each. Read the code, because stored procedures, event handlers, macros, and save-time validation state what the system does rather than what people remember. Query the data, because distributions and gaps expose logic the code no longer contains. Interview the people, because intent lives with them, then validate each recovered rule against real cases before recording it. And catalog the workarounds, because a spreadsheet beside the application or an approval sent by email is a rule the system failed to carry and a requirement candidate for whatever replaces it, not a requirement until a real case shows the need.

Why do rebuild projects blow their scope?

Four causes recur, each one addressed directly by discovery. Rules found after the scope is signed arrive as change requests rather than requirements. Integrations counted as one system turn out to be several interfaces with separate formats, owners, and release calendars. Data cleanup deferred to migration becomes an unplanned project inside a planned one, at the point of maximum schedule pressure. And the operating model nobody documented surfaces when real users meet software that implements the process as designed instead of as run. Each cause is cheaper to find before a scope is fixed than after it.

What must be true before we scope a rebuild?

The inventories are counted rather than asserted, with row counts, key integrity, and interface owners verified. The business rules are recovered and traced to a source. The success criteria are written in terms someone will sign, including the reconciliation and the switch-off conditions. The data statement names what moves, what is corrected, what is archived, and what is abandoned. A risk list records what discovery could not resolve, because that list is what contingency is priced against. And the signatures are on the artifacts, from the business owner, the data owner, the interface owners, and IT.

Can we run this discovery with our own team?

Frequently yes, and the test is whether the team has three things: someone who can read the legacy code with authority, access to a data copy they are allowed to profile, and enough distance from the system to record how it behaves rather than how it was meant to behave. Two of the three is not enough on its own: whichever one is missing names the part to source, from outside or from inside once someone is given the access and the time. Internal teams hold an advantage on access and history and a disadvantage on distance, because the workarounds they live with are invisible to them. Where an outside pair of eyes earns its fee is on the rule archaeology, and on writing down the things everyone assumed were obvious.

What does a discovery sign-off actually contain?

Named signatures against named artifacts, with the meaning of each signature written above it. The business owner attests that the function inventory, the user and role map, the rule register, and the success criteria describe the system as it is operated. The data owner attests to the data statement, including the records deliberately left behind. Each integration owner attests to their own interface. IT attests to the data inventory, the integration inventory, and the risk list. A sign-off that says only “reviewed” is not a sign-off, because it commits nobody to the description the estimate was built on.

Is discovery different when the target is Power Platform rather than a custom rebuild?

Yes, enough that the two are separate exercises. Discovery aimed at a custom rebuild concentrates on recovering business rules, integration contracts, and data reality in detail, because the new system reimplements them line by line. Discovery aimed at a Power Platform build concentrates on process truth, whether the data model fits Dataverse, where delegation limits bite, what licensing the user population implies, and who owns the app after go-live. The inventory work overlaps. The judgments do not, and running the wrong one produces a scope aimed at the wrong destination.

Related Reading

• IT Systems Analysis Services for Enterprise Microsoft Environments, the assessment engagement when the question spans an estate rather than one application
• Modernize Legacy Systems without Disrupting the Enterprise, how a modernization program is sequenced once the decisions are made
• Transform Excel Spreadsheets into Enterprise-Ready Web Applications, the same recovery problem when the legacy system is a spreadsheet

About the Author

Michael Branson co-founded i3solutions and brings executive, operational, and technical perspective to organizations running complex, secure, and mission-critical Microsoft estates. He works with enterprise teams on the governance models that keep platform investments auditable and alive.