What Discovery Actually Looks Like: A Week-by-Week Walkthrough

Discovery is where a migration either gets scoped correctly or doesn't. Here's a realistic week-by-week walkthrough of what a real discovery phase covers — data inventory, the custom-to-custom audit, third-party evaluation, and a phased plan — so you know what to expect, and what to demand from any partner running it.

Last verified: September 6, 2026.

Why discovery deserves a worked example

The hub and anchor spokes in this series explain the principles: extract-transform-load, the custom-to-custom trap, third-party survival. This piece exists to show what applying those principles looks like day by day, rather than leaving them abstract. If you're evaluating a partner's discovery process, this is the shape a real one takes.

The six weeks below are a sequence, not a schedule. What matters is the order — nothing in week three can be answered before week one is done — and that every one of these workstreams happens somewhere before a build is scoped. A partner who proposes a two-week discovery isn't necessarily wrong; a partner who can't say which of these six pieces of work their two weeks contains is.

Week 1: Data and systems inventory

The first week is almost entirely investigative rather than decisional. A real discovery process starts by mapping every system that touches commerce data — the core platform, any ERP or OMS, payment processors, tax engines, fulfillment systems, and marketing tools. For each, identify what data it owns, what format that data is in, and how it currently connects to everything else.

This week produces a system map, not a plan. You can't scope a migration accurately without first knowing everything that's actually involved, and the systems that surface late are reliably the expensive ones — the internal reporting tool that reads directly from the production database, the scheduled job nobody owns, the integration built for a partner who no longer exists but whose feed still runs.

Week 2: The custom-to-custom audit begins

With the system map in hand, the team starts cataloging every piece of custom functionality on the current platform: every custom feature, workflow, and business rule. Each item gets tagged as either a genuine, current business requirement or a workaround for a limitation on the current platform.

This is where interviews with the people who use the system daily matter more than reading whatever documentation exists. Documentation is often outdated; the people doing the work know what's actually load-bearing and what's vestigial. Ask what someone does when the system won't let them do the obvious thing — the answer is almost always a workaround that has since been written down as a requirement. The full audit covers how to run this without putting the team on the defensive.

Week 3: Mapping against the destination platform

Every item flagged as a possible workaround in week two gets checked against Shopify's current native capability — not against what Shopify could do years ago, but against what it can do now.

This is where a meaningful share of the original must-have custom list typically shrinks, once someone actually checks rather than assumes. The output is a much shorter, more honest list of what genuinely needs custom development, and — just as usefully — a written record of why each surviving item survived. That record is what stops the list quietly re-growing during the build.

Week 4: Third-party system evaluation

Running in parallel with the platform-capability check, every third-party integration gets evaluated against the framework in which third parties should survive your migration: does it already work well with Shopify, is it actually causing a problem today, and would replacing it stack a second learning curve on top of the platform change.

Work down from the systems carrying the most operational weight. Payment, order management and fulfillment decisions change the build estimate; a reviews widget does not. The long tail can be batched into a single review and defaulted to keep unless something specific argues otherwise.

Week 5: Data migration planning

With the systems and requirements now clear, the team builds the actual extract-transform-load plan: what data comes from where, how it has to transform to fit Shopify's model, and how parity will be tested. The ETL method is the reference; this week turns it into a specific plan against your specific data.

This is also when data cleanliness issues surface — duplicate SKUs, inconsistent categorization, orphaned records, order history whose true depth nobody has agreed on. Those affect the realistic timeline more than almost any other single factor, and finding them in week five is a considerably better outcome than finding them during a load.

Week 6: The phased plan and business case

Discovery concludes with a real, sequenced plan: what gets built first, what depends on what, named ownership for each phase, and a realistic timeline range based on everything learned in the previous five weeks rather than a best-case guess made before any of it happened.

This is also typically when the business case gets finalized for executive approval, now grounded in real findings. A business case written before discovery is a forecast. One written after it is an estimate, and the difference is visible to anyone who has approved both.

Why six weeks, and why that isn't wasted time

Six weeks before a single line of migration code gets written can feel like a delay to a team eager to move. It isn't. It's the phase that determines whether the following months of build work are scoped against reality or against a guess.

Every discipline covered elsewhere in this series has to happen somewhere. Discovery is where it happens before money gets spent building the wrong thing, rather than during the build, when correcting course costs several times more. A custom requirement caught in week three costs a conversation. The same requirement caught in month four costs a re-scope, and possibly a re-quote.

What a compressed discovery looks like under real time pressure

Not every migration has six calm weeks — see the trigger framework for why urgency is often the actual starting condition.

A compressed discovery doesn't skip these six weeks of work. It runs them in parallel with more people. buybuy BABY's full rebuild ran 31 days including discovery — 30,000+ SKUs, 8.3 million customer records off Oracle ATG, and 14 integration points live at launch. The sequence stayed the same; only the calendar compressed, and the cost of that compression was paid in people rather than in skipped work.

What genuinely can't compress is week one. Everything downstream depends on knowing what systems exist, and a parallel team working from an incomplete inventory is a parallel team producing plans for the wrong system.

What to ask a prospective partner about their discovery process

Ask for a specific example of a past discovery phase — not the outcome, the process. Did they interview actual system users, or only read documentation? Did they check custom requirements against current platform capability, or accept the existing requirements list as accurate? What did the phase produce as a written artifact?

A partner with a real, repeatable discovery process can walk through it at that level of detail. One without will describe discovery in terms of getting to know your business, without being able to say what that actually produces. It's the same test that works on an ETL method: a real process can be described in the abstract, before anyone mentions your platform.

Frequently Asked Questions

How long should discovery take for an enterprise Shopify migration?

It varies with complexity, but a real discovery process for a meaningfully complex migration typically runs several weeks, covering systems inventory, the custom-to-custom audit, third-party evaluation, and data migration planning. Rushing this phase is where downstream scoping problems usually originate.

Can discovery be compressed for an urgent migration?

Yes, by running the same work in parallel with more people rather than by skipping steps. buybuy BABY's full migration including discovery ran 31 days, and every discipline still happened on a compressed calendar.

What should discovery actually produce?

A system inventory, an honest and usually shortened custom-requirements list, a keep-or-replace decision for each integration, a data migration plan, and a phased build plan with named ownership — not just a general sense of understanding the business.

Which part of discovery can't be shortened?

The systems inventory. Everything downstream depends on knowing what exists, and parallel workstreams built on an incomplete inventory produce plans for the wrong system.

If you want to know what discovery would surface in your case, talk to an architect — it's the first phase of a systems replatform.