Netlify ran a customer story this year about Mattel. Real Mattel: Barbie, Hot Wheels, Fisher Price, American Girl, the whole catalog. The scale is the headline. Five hundred plus digital properties consolidated onto a single platform. Seventy plus brand sites, corporate sites, internal services. Zero emergency calls to the Senior Director of Digital Technology since the migration.
Five hundred sites is a lot of sites. The case is interesting not because most of us are running five hundred sites (we are not), but because the math of "how do I keep this manageable" is the same whether you have one site or fifty. The shapes scale up and down, and the lessons are mostly the same.
I want to extract what is actually useful here, ignore the marketing shape, and turn it into something a solo builder or a small agency can apply.
The setup, in plain terms
Mattel's stack before the migration was the typical Big Company Web Estate. Some sites lived on their own servers, in their own colo or AWS account. Some were built on cloud applications they bought. Some were behind WordPress, some behind static deployments, some behind Shopify with a layer of custom proxies. Each property had its own auth, its own deploy process, its own incident pager, its own person on the hook.
Mark Hall, the Senior Director who tells the story, called it "death by a thousand cuts." Each individual problem was small. The bookkeeping of which problems lived on which platforms, and which person on which team owned the fix, was the actual cost.
The goal was simple to state and hard to do: separate the e-commerce-shaped traffic from everything else, and put everything-else on one platform that full-stack developers could own end-to-end without needing a sysadmin, a cloud admin, and a network admin in the room for routine changes.
Three years in: the consolidation worked. Eighteen sites are running serverless functions through Netlify, the deploy flow is Git plus CI, and Mark, the senior director, no longer gets the late-night phone calls. The teams now spend their cycles on React app code instead of EC2 babysitting.
What this is actually saying
Strip the words and the case is a recipe with three ingredients:
-
Separate the things with different shapes. Commerce traffic has different scale, latency, fraud, and compliance characteristics than corporate-marketing traffic. Mixing them on one stack means you tune for the worst case on every node and pay for it everywhere. Mattel split commerce onto Shopify with a Netlify proxy layer for custom features, and put everything else on Netlify directly. Two stacks, each tuned for what it actually does.
-
Reduce the number of platforms developers have to context-switch between. Every separate platform has a deploy process, a billing dashboard, a security model, a CLI, a status page. Each context switch costs five minutes. Five minutes times five platforms times twenty engineers times daily operations adds up to weeks of wall-clock time per year, before anything goes wrong.
-
Push deploys behind Git, not behind a control panel. Mattel's deploys are CI-driven from a Git push. A junior dev can ship the same way a senior does. The whole thing is reviewable, revertible, auditable. When the platform supports this natively, the change is mostly just turning it on. When it doesn't, you build it yourself, and the build is half a year of platform engineering.
That's the whole pattern. The five-hundred-property number is impressive. The pattern works for one developer with five sites the same way it works for a Fortune 500 with five hundred.
What to actually do with this if you're not Mattel
I run a stack of about thirty active properties, plus another twenty in various states of maintenance and archive. I've felt the same pain at smaller scale. Here's what I'd do, ranked by ease and impact, if I were starting over:
1) Pick one platform per workload type, not per site.
Don't put one site on Vercel because that's where you used Next.js, another on Cloudflare Pages because you tried it, another on Render because somebody on Twitter recommended it, another on Netlify because that was the first one you signed up for. Pick one platform for each kind of thing you do, and make every site of that kind go there.
In my own stack:
- Static + small functions → Netlify (one place, one billing dashboard, one CLI).
- Heavy compute or always-on services → a single VPS host, Hetzner specifically.
- Anything Postgres → managed Postgres at one provider, even when the platform offers its own (so I can migrate the platform without migrating the data).
If you're starting from zero, the right number is one platform per workload. If you're 80% on one platform and 20% scattered, the right next step is consolidating the 20%.
2) Move deploys behind Git on every site.
Even tiny sites. A static one-pager? Git push to a static branch. Eleventy site? Git push, build, deploy. WordPress with a custom theme? You can put the theme in Git and rsync the rendered output. Whatever your site is, pushing code to a branch should be the only act that changes production. No FTP. No "I edited the file in the dashboard." If a non-Git change is the only way to fix something, you've found a thing the platform can't do, and you should write that thing down.
3) Treat your stack inventory as a real document.
Mark Hall at Mattel implicitly was running a "what platforms do we have, and who owns each thing" inventory in his head. The migration was the project of writing that inventory down on paper, then deciding what to delete versus what to consolidate.
You can do this in twenty minutes for a small stack. List every site, every domain, every service. For each one, write the platform it lives on, who can deploy to it, and the last time you actually changed the code. The list is the project plan. Anything you haven't touched in 12 months is a candidate for deletion or archival, not migration.
4) Stop pre-optimizing for "what if I outgrow this."
The most common mistake at the small-operator scale is choosing a platform because of what you might need in three years, not what you actually do now. Mattel is on Netlify because the migration came back as a strategic platform fit, not because Netlify is the fanciest available option. The fanciest option costs you in setup time, learning curve, and platform-specific knowledge that transfers to nothing else. The simplest option that does the job today, and that has a credible path forward, wins almost every time.
What's not in the marketing copy
The case study glosses past three things that matter when you actually do this kind of consolidation:
The migration takes longer than the platform vendor will tell you. Mattel's case mentions "three years in." Three years for five hundred sites is two days per site, on average. That's roughly the right pace for a consolidation that's done well: enough time per site to actually understand what it does, refactor where it makes sense, and verify the new deployment doesn't lose anything subtle. Plan for that pace, not the "we migrated everything in a weekend" pace the case studies imply.
The hardest sites to migrate are the ones nobody owns. Pre-existing legacy sites where the original developer left, the original product manager left, and the only documentation is the running site itself. These are the sites you discover bugs in by migrating, because the migration is the first time anyone has read the code in five years. Budget extra time for these.
You will inherit governance work you didn't plan for. Once everything lives on one platform, you have to define who can deploy to what, who pays for which workload, and how new sites get spun up. Mattel calls this "light governance." It's still governance. Plan for someone to own the platform itself, separate from owning any individual site on it.
The lesson, ranked
If I had to pick one thing from the Mattel case to take home, it would be this: the cost of running five different platforms is not five times the cost of running one. It is much higher than that, because the cost of context switching scales superlinearly. A solo operator on three platforms pays more attention-cost than a five-person team on one. The math is not about your scale. It's about your shape.
The five-hundred-property number is a vanity metric for a case study. The interesting number is "zero emergency calls to the senior director, three years in." That's what you're actually buying when you consolidate. Not the savings on hosting. The savings on the calls.
I covered the network-architecture side of running many properties, including how to think about consolidation, in The $100 Network, the third book in the Digital Empire trilogy. The chapter on stack-shape rules (chapter 16) is where I argue the same thing in book form: pick a shape, stick to it, and your maintenance cost goes from O(N) to roughly O(1) once the shape is right.
Related reading
- Cross-Domain Entity Consistency covers the related case where one operator runs multiple domains and needs them to look like one entity to AI search.
- The Tribute Microsite Pattern is what you do when you keep a microsite as a separate property but funnel its authority back to the master.
- Cross-Site Link Hygiene is what you do once your stack is consolidated and you need the inter-site signals to match the architecture.
- The Mega Analyzer is what I use to confirm that a newly-migrated site didn't lose anything during the move.
- The Hosting Indexing Health Checker is a related post on validating that a hosting platform's defaults aren't quietly hurting your indexable content.
Fact-check notes and sources
- Source: Netlify customer case study on Mattel, How Mattel Consolidated 500+ Digital Properties on a Single Platform, retrieved 2026-05-05.
- Quoted speaker: Mark Hall, Senior Director of Digital Technology at Mattel, per the same case study. Direct quotes here are paraphrased and clearly framed as paraphrases; the only direct phrase reproduced verbatim is "death by a thousand cuts."
- Mattel brand list (Barbie, Hot Wheels, Fisher Price, American Girl) per Mattel's corporate brand portfolio.
- Three-year migration window per the case study; specific per-site migration pace is my analysis, not Mattel's claim.
- Stack-shape and platform-consolidation framing reflects my own opinion. I'm not a Netlify customer-success engineer and have no relationship with Mattel. The recommendations here are general-purpose; pick the platform that fits your actual situation.
This post is informational, not infrastructure-consulting advice. Mentions of Mattel, Netlify, Vercel, Cloudflare, Hetzner, Shopify, and other third-party products are nominative fair use; no affiliation is implied.
