The Complete Commerce Replatform Checklist

Summary

A phase-by-phase checklist covering the critical questions most replatform projects skip, from pre-discovery through delivery. Use this to pressure-test your approach before gaps turn into scope explosions.

Generic Checklists Ask the Wrong Questions

Most replatform checklists ask obvious questions: "Do you have a timeline?" "What's your budget?" These get checkbox answers that don't surface real risk.

The hard questions expose misalignment between stakeholders, force trade-off conversations early, and reveal assumptions hiding in plain sight.

Some questions here will feel uncomfortable. That's the point. A question that makes a stakeholder pause is worth more than ten that get instant agreement.

Treat This as a Pressure Test, Not a Form

If you can't answer a question clearly, that's a gap worth investigating
If two stakeholders give different answers, that's misalignment worth resolving
If an answer is "we'll figure it out later," that's risk worth quantifying

Work through each phase before moving to the next. Gaps compound. A question you skip in pre-discovery becomes an assumption in architecture, then a change order in delivery.

Phase 1: Pre-Discovery

These questions determine whether you're ready to start discovery, or whether you're about to scope a moving target.

Strategic Alignment

What specific business outcome is this replatform supposed to achieve, and how will you measure it?
Who is the single decision-maker for platform selection, and do they have authority to override departmental preferences?
What happens to this initiative if budget gets cut by 30%? By 50%?
Has the organization attempted a replatform before? What happened?
Is there executive sponsorship beyond the project owner, and have they committed time?

Organizational Readiness

Which teams will need to change their daily workflows, and have they been consulted?
Who currently "owns" the commerce experience, and will that ownership change post-launch?
What's the organization's track record on projects requiring cross-departmental coordination?
Are there any planned organizational changes (restructures, M&A, leadership transitions) in the next 18 months?
How does IT capacity look for the proposed timeline? What else is competing for their attention?

Current State Clarity

When was the last time someone mapped the full order lifecycle end-to-end, including exceptions?
What percentage of current platform functionality is actually used vs. configured but ignored?
Are there undocumented integrations, scripts, or workarounds that only one person understands?
What would break first if the current platform went down for 48 hours?
How much revenue flows through the commerce platform monthly, and what's an acceptable downtime window?

Phase 2: Discovery

Discovery should produce decisions, not just documentation.

Business Requirements

Which current capabilities are non-negotiable vs. "nice to have" vs. "we've always done it this way"?
What business processes exist only because of platform limitations that could be eliminated?
Where do customer complaints cluster, and which are platform-related vs. operational?
What reporting do stakeholders actually use weekly vs. what exists but gets ignored?
Are there seasonal or promotional patterns that require specific platform behaviors?

The Stakeholders Who Will Block You

Who will block this project if they feel unheard, and what do they need to feel heard?
Which stakeholders have been burned by past technology projects, and what are their specific concerns?
Are there conflicting KPIs between departments that will surface as feature fights?
Who has undocumented requirements living only in their head?
What's the real reason the last platform was chosen, and who made that decision?

Integration Landscape

For each integration: who owns it, when was it last modified, and what happens if it fails?
Which integrations are synchronous and blocking vs. asynchronous and recoverable?
Are there batch processes that appear simple but handle critical exceptions?
What data transformations happen between systems that aren't documented?
Which third-party contracts are up for renewal during the project timeline?

Data Quality vs. Data Assumptions

What's the actual data quality in the current system, not the assumed quality?
Are there duplicate records, orphaned data, or fields used for unintended purposes?
How much historical data needs to migrate vs. archive vs. can be abandoned?
Who decides what "clean" data looks like, and have they seen the raw exports?
Are there compliance or data residency requirements that constrain migration options?

Phase 3: Architecture

Architecture decisions made without traceability become "that's just how it was built" within six months.

Platform Fit

What are the three things this platform must do exceptionally well, and does the selected platform actually excel at them?
Where does the platform's native model conflict with how the business actually operates?
What's the platform's upgrade path, and how will customizations survive upgrades?
How does the platform handle the edge cases that cause 80% of support tickets?
What's the vendor's track record with clients at this scale and complexity?

Where Customization Creates Debt

What customizations are planned, and what's the maintenance burden for each over five years?
Where is the business willing to adapt process to fit the platform vs. requiring the platform to adapt?
Which integrations can use standard connectors vs. require custom development?
What's the strategy when a business requirement conflicts with platform best practices?
How will you evaluate "build vs. buy" for each capability gap?

Technical Foundation

What's the performance baseline required, and how will you validate it before launch?
How does the architecture handle failure in each integration point?
What's the disaster recovery approach, and when was it last tested?
How will environments be managed across development, staging, and production?
What's the security model, and who reviews it?

Designing for Year Two and Beyond

How will this architecture accommodate the roadmap items planned for years two and three?
What's the cost model at 2x and 5x current transaction volume?
How does the architecture support multi-market or multi-brand expansion if needed?
What would need to change to support a major channel addition (marketplace, B2B, etc.)?
Where are you intentionally taking on technical debt, and what's the payback plan?

Phase 4: Estimation

Bad estimates aren't guessing problems, they're scoping problems.

What's Actually In Scope

What's explicitly out of scope, and has everyone agreed in writing?
Which requirements are still marked "TBD" and who owns resolving them by when?
What assumptions are baked into the estimate, and what happens if they're wrong?
Are there dependencies on client deliverables, and what's the delay impact if they slip?
What's the buffer for requirements that will emerge during build?

Complexity Factors

Which components have been estimated by someone who's built them before vs. someone guessing?
What's the data migration estimate based on, actual data profiling or row counts?
How much time is allocated for environment setup, DevOps configuration, and pipeline creation?
What's the estimate for testing, and does it include regression, performance, and UAT?
How are change requests handled contractually and operationally?

Resource Reality

Are the people who estimated the work the same people who will execute it?
What's the client's availability for decisions, reviews, and approvals?
Are there single points of failure on either team for critical knowledge?
How does the team handle knowledge transfer if someone leaves mid-project?
What's the realistic ramp-up time for team members new to this platform or client?

Phase 5: Delivery

By delivery, most critical decisions should be made. These questions catch what's still unresolved.

Go-Live Criteria That Actually Mean Something

What are the specific, measurable criteria for go-live, not "stakeholder approval"?
What's the rollback plan if critical issues emerge post-launch?
Who has authority to make the go/no-go call, and what information do they need?
What's the hypercare plan for the first 30 days post-launch?
How will you monitor for issues that users won't report?

Cutover Planning

What's the exact sequence of cutover steps, and how long does each take?
What data needs to be frozen, migrated, or synchronized during cutover?
Who's on call during cutover, and what's the escalation path?
What customer communications are planned before, during, and after cutover?
What's the maximum acceptable cutover window, and what happens if it's exceeded?

Operational Handoff

Who owns the platform on day 31, and are they ready?
What documentation actually exists vs. what's planned but not written?
How will the operations team handle issues they haven't seen before?
What training has been completed vs. scheduled vs. not planned?
What's the support model with the implementation partner post-launch?

Measuring Whether This Actually Worked

How will you know in 90 days whether this replatform succeeded?
What metrics are being tracked before launch to enable comparison?
Who's accountable for the business outcomes, not just the technical delivery?
What's the plan if the expected benefits don't materialize?
When is the formal project retrospective, and who's required to attend?

How DigitalStack Structures This

DigitalStack captures checklist responses in a system that maintains context across phases.

Stakeholder input flows through scored surveys rather than scattered emails. Requirements trace directly to architecture decisions, when an integration dependency changes, you see which estimates are affected. When a stakeholder raises a concern, it links to the objective it impacts.

Gaps surface automatically instead of hiding in slide decks. Decisions stay traceable. Context survives the project.

Next Step

Audit your current replatform approach against this checklist. Where are stakeholders misaligned? Where are you relying on assumptions instead of answers?

If your discovery process can't capture and connect this level of detail, your architecture and estimates are built on sand.

[See how DigitalStack structures replatform discovery →]