What 18 months of building an internal platform — and driving tenant adoption — have taught me. The common mistakes, and six phases for doing it right.
The strange quiet after launch
Six months after we built and launched an internal platform, I thought adoption would be easy. The reality couldn’t have been more different. Adoption often takes longer than expected because tenant teams already have working systems, and migration carries real cost. The new system is working. The integration guide exists. The kickoff meetings have happened. And yet the pace of migration is slower than expected.
Building a platform has a kind of urgency. There are sprints, demos, design reviews, exec readouts, and finally a launch announcement. Architecture diagrams get refined each week. A go-live date appears on a roadmap, and everyone sprints toward it. Then the platform ships, and the real work starts.
I’ve spent the last 18 months building and launching an internal platform at Walmart and have been leading its tenant onboarding. This is a piece about what I’ve learned — including the mistakes — about platform adoption.
AI Generated ImageThe most expensive assumption in platform engineering: “If we build it, they will come.”
It is comforting because it makes adoption someone else’s problem. The platform team builds; the tenant teams choose. We tell ourselves that if the platform is good enough, the choice will be easy.
But the tenant team already has a working system. It is integrated, instrumented, and understood. It carries years of bug fixes and accumulated edge cases. When tenant teams are asked to migrate, it feels like taking on a tax — engineering effort, regression risk, calendar pressure — in exchange for a benefit that mostly accrues down the road, while pulling engineering bandwidth away from higher-priority work today.
Yes, there are real benefits: consistency across the company, a lower long-term cost of ownership, shared capabilities that scale across teams, and capabilities they don’t have to build themselves. None of it solves the immediate problems on the tenant’s plate — the feature an executive asked about last week, the P0 from the last incident review, or the customer-impacting bug they are committed to fixing this sprint.
Building a platform is an internal effort with internal control. The team owns the scope, the timeline, the architecture, and the tradeoffs.
Adoption is the opposite. The platform team owns none of the inputs that decide whether a tenant migrates: not their roadmap, not their funding, not their engineers, not their executive priorities. The platform team can only influence — through clarity, support, incentives, and the relentless reduction of friction.
That asymmetry is the whole game. And it leads to a useful inversion: The platform is not the product. Adoption is the product.
Once you accept that, a few things change in practice. Roadmaps stop ending at launch. Team composition shifts to include dedicated capacity — net-new — for helping tenants migrate. Quarterly reviews start tracking adoption metrics — tenants live, percent of traffic on the new platform; legacy systems sunset — not just features shipped.
Part 1 — Four principles for driving adoption
1. Solve a problem the tenant already has
Most platforms are designed around a problem the platform team has — fragmented infrastructure, duplicated logic, and inconsistent governance. Those are real problems, but they are not the tenant’s problems. A tenant team is not lying awake at night thinking about your fragmented landscape; they are thinking about their own backlog.
Adoption begins when you can articulate, in the tenant’s own words, a problem of theirs the platform makes go away. A capability they could not build alone. An operational burden they no longer have to carry. A class of incidents they stop owning. If you cannot finish the sentence “this saves the tenant from ___”, they will not migrate, no matter how elegant the architecture.
2. Earn adoption phase-by-phase, never in a big bang
The instinct is to push for a single, decisive cutover — it looks clean on a roadmap and reads well in a steer-co deck. In practice, it is the most reliable way to lose the tenant.
Phased adoption — read-only first, then dual-write, then read-and-write, then sunset of the legacy — gives the tenant escape valves at every step. It also gives the platform team early signal: every phase that succeeds builds confidence; every phase that struggles surfaces problems while they are still cheap to fix. Big-bang migrations turn every defect into an emergency. Phased migrations turn defects into normal work.
There is a real cost to this approach: it requires legacy and new systems to coexist for longer, which means dual-running infrastructure, additional reconciliation, and a longer window where the tenant carries two mental models. For small, isolated, low-blast-radius migrations, a clean cutover may genuinely be cheaper. The phased model earns its keep when the migration touches customer-facing flows, sensitive data, or downstream consumers the tenant doesn’t fully control.
3. Ship an MVP; let tenant adoption shape what comes next
The instinct is to build everything tenants might eventually want before launch — an exhaustive platform, feature-complete on day one. It feels safer. It isn’t.
An over-scoped platform at launch makes adoption harder, not easier. Tenants have to evaluate every capability against their backlog. Roadmap conversations drown in feature debates. And the team that built all those capabilities has no bandwidth left to help anyone migrate.
The better path: ship a narrow MVP that solves one real tenant problem completely. Then let the first three to five tenant migrations tell you what to build next. Net-new features earn their place on the roadmap by being asked for by a live tenant with real traffic on the platform — not imagined by the platform team in isolation.
4. Treat the early tenant as a co-builder — of the integration and the roadmap
A “customer” model puts the platform team in the position of vendor: we ship, they consume, support tickets are filed, SLAs are negotiated. It produces a measurable distance between the two teams.
The “co-builder” model is different. The tenant participates in the requirements that shape the platform. They join the design reviews for the integration that affects them. They have named DRIs on both sides for every workstream. And, crucially, their asks shape the net-new feature roadmap — the platform grows with them.
A tenant who feels co-ownership of the integration — and co-authorship of the roadmap — will defend it internally, prioritize it on their roadmap, and absorb the inevitable bumps that are part of migration and product launches.
From principles to practice
Principles are necessary but not sufficient. A tenant team walking into a kickoff meeting needs to know, concretely: what happens this week, what happens next month, what the upcoming milestones are, and who signs off on what. That is what a playbook is for — to enable a scalable tenant onboarding.
Part 2 — The six phases of a tenant onboarding
Phase 1 — Discovery
Discovery is two parts: alignment, then deep-dive.
In the alignment half, the platform team walks the tenant through what is available off-the-shelf, what requires configuration, and what would be a net-new build. The tenant team maps its full landscape — every category they own, every upstream producer, every downstream consumer, and any growth use cases coming in the next one to two quarters. Together, the teams produce an integration inventory and select the first capability to onboard to.
In the deep-dive half, both teams run structured requirements sessions for the in-scope capability — user stories, edge cases, data formats, field mappings, integration contracts. The platform team then runs a platform assessment: every requirement is classified as off-the-shelf, configuration-needed, or net-new build. Gaps from this assessment become the work items in Phase 2.
The phase ends when both teams sign off on a joint PRD covering user stories, architecture diagrams, integration inventory, platform assessment, data maps, and payload specs. The roadmap is agreed.
Phase 2 — LOE and sizing
Engineering on both sides (platform and tenant) estimates the work independently, then aligns.
The platform team sizes tenancy and configuration work, any net-new platform capabilities identified in the assessment, and the integration support needed (API changes, documentation, test environments). The tenant team sizes upstream re-pointing, downstream consumer updates, and migration of any existing data including transformations and cleanup.
Phase 3 — Engineering resourcing
Two things must be confirmed before development can begin:
- Engineering allocation on both sides
- Named DRIs for every workstream.
Two things should also be in place: a recurring joint working cadence between the engineering teams (weekly during active development), and shared test and staging environments with an agreed branching strategy.
Phase 4 — Development
Joint sprint planning, parallel build, continuous integration testing.
The platform team configures the tenant, builds any net-new capabilities, and stands up operational telemetry and orchestration as applicable. The tenant team re-points its upstreams, updates its downstreams, and migrates its data — validating data integrity sprint-by-sprint, not at UAT.
Two non-negotiables we learned the hard way:
- End-to-end testing happens continuously, not at the end. Signal propagation across downstream systems is validated every sprint.
- The rollback plan is built and rehearsed in staging before UAT begins. If you don’t have a tested rollback, you don’t have a launch plan — you have a hope.
Phase 5 — UAT
UAT is comprehensive and joint. It covers four areas:
- Functional testing — every capability reads and writes correctly through the platform, signals propagate to all downstream systems in real time, evidence is traceable and retrievable and aligned to requirements.
- Integration testing on both sides — every upstream producer validated, every downstream consumer validated, platform APIs validated at expected load and latency.
- Compliance and legal review — where required, legal and compliance teams review and sign off as part of UAT, not after.
- Launch readiness — rollback plan documented and tested, legacy sunset plan confirmed with all dependent teams, monitoring, alerting and SLA dashboards live, staged rollout plan agreed.
Phase 6 — Launch
Launch is staged, monitored, and reversible.
The cohort is launched first — a small slice of traffic where reads, writes, and downstream behavior are watched closely before the rollout opens up. Rollback can be triggered at any point by either team, per the plan rehearsed in Phase 4. Once the new system is validated in production, the legacy backend is decommissioned, but only after every dependent team has confirmed cutover. Dashboards, alerting, operational telemetry, and SLA tracking all go live in production at the same time.
A 30-day post-launch retrospective closes the phase. Both teams document what worked, what didn’t, and what changes to make to the playbook itself. The playbook gets a new revision after every onboarding — this is how the next tenant moves faster than the last.
It is tempting to celebrate the platform launch as the milestone. The launch matters. But the milestone that actually decides whether the platform was worth building comes later — the day the final tenant onboards without requiring white-glove support, because the platform was built right, is configurable, and the onboarding playbook works.
The platforms that win at Walmart scale are not the ones with the cleverest architecture. They are the ones whose teams understood, from day one, that the platform was never the product. Adoption was.
From Build to Adoption: A Playbook for Driving Platform Migration was originally published in Walmart Global Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.
Introduction to Malware Binary Triage (IMBT) Course
Looking to level up your skills? Get 10% off using coupon code: MWNEWS10 for any flavor.
Enroll Now and Save 10%: Coupon Code MWNEWS10
Note: Affiliate link – your enrollment helps support this platform at no extra cost to you.