What Should an Enterprise Microsoft Discovery Workshop Produce?

By Michael Branson | August 24, 2026

Quick answer. An enterprise Microsoft discovery workshop should produce five artifacts: an inventory with named owners, a constraints register, a prioritized problem list, the next decision with its options, and the evidence gaps. Anything that reads as a sales deck rather than a decision record has failed.

The disappointing version of paid discovery is not a bad experience. It is a good week, a friendly room, a deck at the end, and no way to answer the question the money was meant to answer: what do we do next, and what makes that defensible to the people who fund it. A week is the shape these engagements are commonly sold in, not a requirement of the method, and what follows holds however long yours runs. The difference between that version and a useful one is not the quality of the conversation. It is whether anyone wrote down the things a decision rests on while the conversation was happening.

What a Discovery Workshop Is For, and What It Is Not

A discovery workshop exists to produce two things: a decision, and the evidence base that decision stands on. Everything else in the room is instrumental to those two, and the five artifacts below are those two written down, together with what the evidence could not settle.

That framing matters because the word “workshop” covers two products that look identical from outside. One is an evidence-gathering exercise run by people who will be held to what they write down. The other is a structured way for a vendor to learn your estate at your expense and arrive at a proposal. Both fill the same calendar slots, involve the same seniority of attendee, and end with a document. Only the first leaves you able to act without the firm that ran it.

The test is ownership of the output. If what you receive is a set of artifacts your own team can carry into a budget cycle, brief a different firm on, or execute alone, you bought discovery. If what you receive is a narrative that resolves toward one provider’s scope of work, you bought a proposal with a research phase attached.

Microsoft’s own framing is useful here because it is vendor-neutral about the sequence. The Cloud Adoption Framework’s strategy guidance describes a cloud adoption strategy as something that “connects executive intent to measurable outcomes and sets the standards that every workload team operates within”, and it notes that “Strategy isn’t a one-time exercise” (Develop a cloud adoption strategy). Intent, outcomes, standards: those are decisions and constraints, not slides. A workshop that produces none of them has not started the work it was booked for.

There is a second thing a workshop is not, and it is worth saying plainly because a sponsor’s disappointment shows up after the week, not during it. A workshop is not a substitute for a decision the executive has to make. Discovery narrows options, prices them in effort and risk, and states what remains unknown. The choice stays with the person accountable for the budget, and a week that quietly makes that choice for them has overstepped rather than delivered.

The Five Artifacts a Discovery Workshop Should Leave Behind

Five artifacts are what a funding committee can act on when the conversation is over. Each one has an owner after the room empties and a test that says whether it is real, and the two together are what separate a deliverable from a document.

An inventory with named owners. Not a technology list. A list of the systems, tenants, workloads, integrations and data stores in scope, each with a person who is accountable for it and reachable when the questions come later. Microsoft is direct about why this comes first: “A comprehensive workload inventory is the foundation of a solid cloud adoption plan”, and “You can’t make decisions about how or whether to migrate a system if you don’t know it exists or understand its characteristics” (Discover your existing workload inventory). The same guidance says the plan “must include steps to discover all workloads, gather key data about each, and prioritize them for migration”. An inventory without owner names is a spreadsheet nobody has to answer for.

A constraints register. The things that are true regardless of what anyone wants: compliance frameworks in force, contractual commitments, tenant boundaries, licensing positions, freeze windows, systems that other programs depend on, and the platform decisions already made and paid for. Constraints are what make an options list honest. A week that produces recommendations without a constraints register is recommending into a vacuum.

A prioritized problem list in the business owner’s words. The problems, ranked, phrased by the person who lives with them rather than translated into platform vocabulary. This is the artifact a room loses when translation happens fast, because the original phrasing carries information the translation drops. When a finance director says the month-end close depends on one person’s laptop, that sentence is more useful to a scoping conversation than “manual dependency in the reporting workflow”.

The decision the executive has to make next, with its options. One decision, named, with at least two options against it, each carrying its consequence, its rough effort shape and its risk. Not a roadmap of everything. The next decision. The Well-Architected Framework is a fair model of what an options discussion owes the reader: it is “founded on the five pillars of architectural excellence”, and “Each pillar provides recommended practices, risk considerations, and tradeoffs” (What is the Azure Well-Architected Framework?). Hold an options list to that standard: a single recommended path with no alternative priced beside it is advocacy wearing an architecture costume.

The evidence gaps. What discovery could not establish, with the effect of each gap on the decision. This is the artifact that proves the other four were produced honestly, and the shortest of the five. An output with no material unknowns left on it is rare enough to be worth checking, and an empty gap list leaves contingency with nothing to price against.

Who Has to Be in the Room, and What Each Role Brings

Attendance is the cheapest determinant of output quality, and the one settled by diary availability rather than by what each artifact needs.

The executive sponsor brings the decision. Without the person who can say yes to a direction, the week produces a recommendation addressed to nobody, and the options list gets re-litigated later by people who were not there for the reasoning. Sponsors do not need to sit through every session; they need to be present when the options are shaped and when the decision is framed.

The business owner brings the problem in its original language, and holds the priority ranking afterwards. Platform and estate owners bring the inventory and the dependencies that sit outside what an admin center reports. Security and compliance bring the constraints that cannot be negotiated in the room, which is precisely why they must be stated in it. Finance brings the funding cycle, and the funding cycle is a constraint like any other: a decision that cannot be presented until the next planning round changes what the options are worth.

One role belongs outside. The person whose compensation depends on the size of the follow-on engagement should not be the person shaping the options list. That is not an accusation of bad faith; it is a structural point about who should hold the pen. The control takes more than one form: a second person holding the pen, a declared split of the room, or an options list written by someone with no stake in which option is chosen. What matters is that the firm names its control at the outset instead of leaving it assumed.

What a Bad Workshop Produces, and How to Tell in the First Hour

A bad workshop produces a well-designed document that nobody can act on alone. It has an executive summary, a maturity model, a set of themes, a phased roadmap with quarters on it, and a recommended next step that happens to be a statement of work. It reads well. It survives no contact with a funding committee, because a committee asks who owns this, what does it cost us to be wrong, and what did you not check.

The tells arrive early, and a buyer sitting in the opening session can read them without technical knowledge:

• Nobody asked for data before the room was booked. A team that intends to build an inventory requests tenant reports, license positions and system lists in advance. A team that intends to build a narrative does not need them.
• The agenda is a capability tour. Sessions named after the provider’s service lines rather than after your decisions produce output organized the same way.
• An architecture appears before your constraints do. A target-state diagram in the opening session was drawn before the room, which means it was drawn without you.
• No one is visibly writing. Artifacts are produced by people taking structured notes against a named output. A room with no scribe produces recollection.
• Budget is asked about as a size, not as a boundary. A team scoping to constraints asks what the budget cannot exceed and why; a team sizing a proposal asks what the number is.

A strong team occasionally arrives with a diagram because a previous client resembled you, so the tells after the first are read together rather than alone. The first tell stands by itself, because a team that booked the room without asking for the estate records first has nothing to build the inventory from. Where several of the others hold together, ask directly whose name goes in the owner column, and listen to whether the answer is a person or a phase.

If you are weighing an offer now and want a second read on what it should leave you holding, Talk to a senior architect. The conversation is about the artifact list and the room, and one honest ending is that the offer in front of you already covers it.

How the Outputs Feed the Engagement Choice and the Capacity Review

Discovery outputs are inputs to two decisions that follow, and keeping those decisions separate is what stops a week of evidence-gathering from becoming a sales funnel.

The first is how to engage. Once the next decision and its options exist, the engagement question becomes answerable with evidence instead of preference. That choice has its own guide and is not re-taught here: Staff Augmentation vs Strategic Delivery Partnership Microsoft sets out the models and where each one holds. Discovery feeds it; discovery does not settle it.

The second is whether your own bench can carry the work the decision implies. Capacity and capability are different questions, and the assessment that answers them is its own exercise, covered by the guide titled “Microsoft Delivery Capacity Review: What to Assess Before Adding a Senior Microsoft Team”. A workshop that ends by asserting you lack the capacity to deliver has skipped that exercise and reached its conclusion.

Between the two sits the plan. Microsoft describes the transition cleanly: “A cloud adoption plan converts your cloud strategy into an actionable plan that’s specific to your goals”, and the same guidance notes that “Successful cloud adoption, whether startup or larger organization, requires more than technical readiness” (Prepare your organization for the cloud). Organizational readiness is the part a live room is well placed to observe, because it shows in how the room answers, and an admin center report does not carry it.

On what discovery costs, this page states no number, and that is deliberate rather than coy: the commercial models, the fixed-scope question, and whether you can execute the roadmap yourself afterwards are set out in How Microsoft Consulting Firms Charge. What belongs here is the yield. It shows when a funding committee can approve or decline on what the artifacts already say, and when the framing survives a reader who was not in the room.

What to Ask a Partner Before You Agree to a Workshop

Six questions settle most of it, and the value is in the shape of the answers more than in their content.

Which artifacts do we hold at the end, and in what format? A firm that has run real discovery names them without pausing, and the format answer says what you can edit and re-issue yourself, not only what you can read. Who writes the inventory, and whose names go in the owner column? The answer should be your people, gathered by their team. What happens if the evidence points away from working with you? The useful answer is a description of how that has gone before, delivered without discomfort. Who is in the room from your side, and are any of them commercially incentivized on the follow-on? Ask for the split explicitly. What do you need from us in advance? A specific list is a good sign; “just the right people in the room” is not. What will you refuse to conclude on the evidence available? Firms comfortable with the limits of a week say so quickly.

The wider method for judging a Microsoft partner, including the criteria and the scorecard, sits with How to Choose Among Microsoft Consulting Companies rather than here; the six questions above are the workshop-specific subset of it.

A buyer who asks those six changes the offer. The point of this page is that a buyer who knows which artifacts to demand raises what firms have to propose, including the ones they do not hire. If you want to pressure-test a scope against them before you sign anything, Talk to a senior architect. That call is a conversation about the scope in front of you, and it can end with nothing worth changing.

How i3solutions Approaches Estate Discovery

i3solutions has worked on enterprise Microsoft estates as a Microsoft partner since 1997, and it is a small senior firm rather than a large bench: the number of estate discoveries running here at any one time is correspondingly small, and a program that needs several parallel workstreams staffed at once should engage a firm built for that volume instead of waiting on this one. Delivery is senior and US-based.

What Microsoft’s own guidance covers is cited to Microsoft above; what a senior team adds is judgment about which constraints bind, when a problem statement is the real one, and what belongs on the evidence-gap list. Tools help with the inventory scan; the decision record is written by the people who will be held to it.

When This Is Not the Work You Need

Some readers should route elsewhere, and it is cheaper to say so here than after a purchase order.

If the question is which Microsoft technologies to keep investing in, consolidate, or retire across the portfolio, that is a technology-portfolio decision with its own method, and Microsoft Technology Stack Evaluation covers it. If the question sits inside one application, and specifically whether to rebuild it, the discovery that has to run first is application-level rather than estate-level, and the guide titled “Enterprise Application Discovery Before a Rebuild” is written for exactly that case. If a program is already failing and the need is a recovery plan rather than an evidence base, a structured week will produce accurate artifacts about a burning building; stabilize first. And if one architect in your organization already holds the inventory, the constraints and the options in their head, the exercise is overhead: ask them to write it down, then take the write-up to the committee.

What is left is the case this page was written for: an estate large enough that nobody holds all of it, a decision with money behind it, and a need for evidence that survives a room the sponsor is not in. The artifacts are the answer, the evidence-gap list is the proof they were built properly, and the ownership of the output is what makes any of it portable. Bring whatever inventory exists and the names of the people who would have to sign off. Talk to a senior architect. The subject is what your discovery has to cover, and one answer is that your own team should run it. The Microsoft Consulting Services Built for Enterprise Complexity practice is where the estate work sits if the answer turns out otherwise.

Frequently Asked Questions

What should a Microsoft discovery workshop produce?

Five artifacts, each with an owner and a test. An inventory of systems, workloads and integrations with a named accountable person against every line. A constraints register citing the policy, contract, license or prior decision behind each entry. A prioritized problem list phrased by the business owners who raised each item. The next executive decision with two or more options costed for effort and for risk. And an evidence-gap list naming what stayed unresolved and what it changes. A deliverable with no gap list is a study that stopped early.

How do we evaluate a discovery workshop deliverable?

Apply three tests. First, ownership: can your team carry the artifacts into a budget cycle, brief a different firm from them, or execute alone without the authors. Second, attribution: does every constraint cite a source and every inventory line carry a named owner, checkable by asking that owner directly. Third, symmetry: are at least two options priced against the decision, with the tradeoff stated well enough that someone outside the room can restate it. A deliverable that resolves toward one provider’s scope of work fails the third test regardless of how well it reads.

What separates real discovery from a sales exercise?

Where the pen sits and who the output serves. Real discovery is organized around your decisions, requests estate data before the room is booked, records constraints before it draws an architecture, and states what it could not establish. A sales exercise is organized around the provider’s service lines, arrives with a target-state diagram, moves quickly to sizing a budget, and ends with a recommended next step that is a statement of work. Both produce a document. Only the first produces a document that works when handed to someone else.

Who should attend an enterprise discovery workshop?

The executive sponsor who owns the decision, the business owners who live with the problems, the platform and estate owners who know the dependencies, security and compliance representatives who hold the non-negotiable constraints, and finance for the funding cycle. Sponsors need not sit through every session, but they should be present when options are shaped and when the decision is framed. One role should not hold the pen on the options list: anyone whose compensation depends on the size of the follow-on engagement, and the firm should name the control it uses instead of leaving it assumed.

What does a good discovery engagement yield?

Either a funding decision a committee can take, or a clear statement of what has to be known first. The yield is measured by whether a committee can approve or decline on the artifacts alone, whether the ranked problems still read as true to the people who raised them, and whether the evidence gaps were small enough to price as contingency rather than large enough to reopen the question. What a discovery engagement costs is a separate subject, covered by the i3solutions guide on how Microsoft consulting firms charge.

Can our own team run the workshop?

Yes, when three conditions hold: someone senior enough to hold the pen without reporting to a stakeholder in the room, access to tenant and estate data they are permitted to pull, and enough distance to record how the estate behaves rather than how it was designed. Internal teams hold an advantage on access and history and a disadvantage on distance, because long-standing workarounds become invisible to the people living with them. Where outside eyes earn a fee is on constraint archaeology and on writing down what everyone assumed was obvious.

What should a discovery workshop not decide?

Three things. It should not decide the engagement model, because choosing how to engage is a separate question decided on its own evidence. It has no business concluding that your bench lacks the capacity to deliver, because capacity and capability need their own assessment rather than a week of observation. And the executive’s choice is not the room’s to make. Discovery narrows options, prices them, and names what remains unknown; the accountable budget holder makes the call.

Related Reading

• IT Systems Analysis Services for Enterprise Microsoft Environments, the assessment engagement when the question is which systems across an estate to upgrade, replace or keep
• IT Systems Analysis Consulting: How Regulated Enterprises Decide Whether to Upgrade, Replace, or Keep Their Systems, the decision method behind that call in a regulated setting
• Boutique vs Global Consulting Firm: Which Is More Cost-Effective for IT Strategy and Assessment?, how firm size changes what an assessment costs and who staffs it

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.