The custom build that got you to $20M won't get you to $50M without a team you don't want to maintain. Custom commerce platforms are usually built for good reasons. Brands move off them for better ones: maintenance cost, talent risk, and the velocity gap between a one-team codebase and a platform 10,000 developers ship features for. Here's the playbook.
Why brands built custom in the first place
There are usually three reasons brands end up on a custom platform.
The legacy reason. The store launched 8, 10, or 15 years ago when the off-the-shelf options didn't exist or weren't credible at scale. The custom build was the right call at the time. Now it's the constraint.
The capability reason. The brand needed something the off-the-shelf platforms didn't do. Subscriptions before Recharge existed. International before Shopify Markets. B2B with custom approval flows. Bespoke pricing logic. Configurators. The custom build solved a real problem the market hadn't yet caught up to.
The control reason. The team wanted complete control over the front-end, the data model, the deployment pipeline. Building custom gave them that. The trade-off is everything that gets built has to be maintained by the same team forever.
All three reasons made sense at the time. None of them age well. The market catches up, the team rotates, and the custom platform becomes the slowest part of the business.
The maintenance tax
A custom commerce platform has running costs that off-the-shelf platforms don't.
Engineering team. Every custom platform needs at least 2 to 4 full-time engineers maintaining the codebase. For a $30M brand, that's $400K to $800K per year in fully-loaded headcount cost. The team gets bigger as the codebase grows.
Single-source-of-knowledge risk. Custom platforms tend to concentrate knowledge in 1 or 2 senior engineers. When they leave, the cost goes up. Some brands end up paying retainers to former employees to remain on call.
Infrastructure. Hosting, monitoring, security patching, scaling for traffic spikes. All of it sits with the brand rather than with a platform vendor. For a mid-market store, this is usually $50K to $200K per year before the dev hours.
Velocity. Every feature is a build. The team ships at the pace of the build queue, not the pace of the market. Compare that to Shopify Plus, where most new features are configurations rather than builds.
The total TCO for a typical custom platform at the $20M to $50M revenue range usually lands at $700K to $1.8M per year including hosting, dev team, and integration maintenance. Shopify Plus typically lands at 30 to 50% of that.
What "the custom platform stack" actually means
Custom platforms vary wildly. The migration audit always starts with the same questions.
Source code review. Where does it live? What language and framework? What's the build and deploy pipeline? Who has access? When was the last commit?
Database schema. Products, customers, orders, cart, sessions, content - where does each live? What are the foreign key relationships? What's the migration extract path?
Front-end framework. React, Vue, server-rendered, headless, or fully custom? The front-end will be rebuilt either as classic Shopify Plus theme or Hydrogen headless.
Integration map. Every external system the platform talks to: ERP, OMS, payment, tax, fraud, email, analytics, search, reviews, subscriptions, loyalty.
Custom logic. Pricing rules, promotion engines, B2B approval workflows, configurators, fulfilment routing, tax calculations beyond what the platform tax engine handles.
Documentation. What exists, what's accurate, and what's only in someone's head. This is usually where the audit reveals the most surprises.
The output of the audit is a build spec, a data migration plan, and a risk register that names every undocumented part of the system.
What changes at the data layer
Custom platforms don't have standard data models. The translation is unique per migration. The work is documented in a catalog mapping before any data moves, but the document is usually 2x the length of an off-the-shelf platform mapping because every field needs explicit treatment.
Products. Custom platforms often store products with non-standard attribute structures. The migration translates each into Shopify products, variants, and metafields. Configurable products, bundles, and configurators usually need explicit decisions: native variant, app-driven, or custom Shopify Function.
Customers. Customer records, addresses, marketing consent, custom fields, and relationship metadata migrate. Passwords don't (see customer account migration). For B2B custom platforms, organisation hierarchies become Shopify B2B companies with locations and contact permissions.
Orders. Order history including line items, payment info, shipping, returns, and order state. Custom order metadata that fed downstream systems gets explicit treatment: stays in Shopify metafields, stays in the receiving system, or gets retired.
Content. Custom platforms often have bespoke CMS-like functionality for landing pages, editorial content, and merchandising. Most of this lands either in Shopify pages, Online Store 2.0 sections, or Sanity for editorial-heavy brands.
Custom data. This is the part that varies most. Loyalty tiers, subscription state, referral relationships, gift card balances, store credit, custom user attributes. Each becomes a metafield, an app entity, or a separate connected system.
Translating bespoke logic
Custom platforms accumulate years of bespoke business logic. The migration is partly a translation exercise.
Pricing rules. Tier-based pricing, customer-segment pricing, time-based pricing, volume discounts. Most translate to Shopify Discounts, B2B catalogues, or Shopify Functions. Complex rule engines may need custom Functions or app-based equivalents.
Promotion engines. Multi-condition promotions, stacking rules, exclusion logic. Shopify Discounts handle the common patterns. Functions handle the rest.
Cart logic. Custom cart calculations, free gift logic, threshold-based offers, bundle discounts. Mostly Functions or apps like Bundler or Shopify's native bundle features.
Checkout customisations. Custom fields, validation rules, address logic. Replaced by checkout extensibility, which gives Plus merchants real customisation without the PCI scope problem custom checkouts have.
Fulfilment routing. Inventory location selection, multi-warehouse routing, drop-ship logic. Shopify's native multi-location with custom routing rules via apps or Functions.
Tax calculation. Most custom tax engines get replaced by Avalara, TaxJar, Vertex, or Shopify Tax depending on geography and complexity.
Reporting and analytics. Custom reports usually move to a combination of Shopify Analytics, BigQuery (via the Shopify connector), and a BI tool like Looker or Mode. Custom dashboards rarely migrate as-is.
The principle: bespoke logic gets reviewed, not preserved. If it was a workaround for missing platform features, it goes. If it's a real business differentiator, it gets rebuilt deliberately.
The integration problem
Custom platforms are usually deeply integrated. ERP, OMS, PIM, fulfilment, payment, tax, email, reviews, loyalty, search, fraud, customer service. Each connection was built by the team and lives somewhere in the codebase.
The migration approach varies by integration depth.
Standalone connectors. Modular integrations that talk to one external system can usually be replaced with Shopify apps, middleware connectors (Boomi, Workato, Celigo), or rebuilt as custom Shopify apps. Lower-effort.
Embedded business logic. Some custom platforms have integration logic deeply mixed with business logic. The order-to-OMS flow has custom rules baked in. Migration means extracting the business logic from the integration code, then rebuilding both separately on Shopify.
Real-time sync requirements. Inventory feeds, pricing updates, customer master sync. These usually need middleware (or a custom app) on Shopify to maintain the same SLA. Plan as 4 to 8 weeks per real-time integration.
A typical custom platform migration includes 6 to 15 integration workstreams running in parallel. The integration list is usually longer than the team remembers.
The documentation problem
Custom platforms run on tribal knowledge. The migration audit usually surfaces three categories of documentation gap.
Undocumented features. Code paths that handle edge cases, special customer types, legacy promotions that have been running for years. Discovered usually by reading the code or interviewing the team.
Documented but stale. Wikis and READMEs from 3 years ago that no longer reflect what the system actually does. Not always reliable.
Documented but only in someone's head. Senior engineers who know the system intimately but haven't written it down. The migration project is sometimes the first time this knowledge gets formalised.
We treat the audit phase as a knowledge extraction exercise. The output isn't just a build spec - it's a complete inventory of what the current system does, accurate enough to be a reference for the rebuild. For brands where senior engineers have hinted at leaving, this matters.
The team conversation
Migrations off custom platforms come with an internal team conversation that doesn't apply to off-the-shelf migrations.
The platform engineers maintaining the custom build have specialised skills. After migration, those skills are no longer needed in the same way. Three patterns are common.
Retrain. Engineers learn Shopify and become full-stack on the new platform. Most senior engineers can make this move in 3 to 6 months. Common for tightly-knit teams.
Reposition. Engineers move into adjacent roles: integration engineering (which is still needed), data engineering, product management, or platform engineering at higher levels of abstraction.
Reduce. Some platform-specific roles don't have direct equivalents on Shopify. Brands sometimes use the migration as a moment to reorganise the team.
The conversation is best had openly and early. Migration projects with unspoken team anxiety run worse than projects where the future state is named.
What we won't do
A few principles that keep the project clean.
We don't replicate logic that's better as native Shopify. If the custom platform was solving for missing platform features, the rebuild uses native or app-based features. Not custom Functions for problems Shopify Plus solves natively.
We don't migrate dead code. Most custom platforms have features that were used twice three years ago. The audit usually shows 30 to 50% of features can be retired with the migration.
We don't ship without integration sign-off. Every integration runs end-to-end on the migration sandbox with sample data before go-live.
We don't ship without 1:1 reconciliation. Product count matches. Customer count matches. Order count matches. Custom data field counts match per record. If anything doesn't reconcile, we don't launch.
We don't sign off on a redirect map we haven't tested. Every URL gets crawled. Every redirect gets verified. For custom platforms with unusual URL structures, this is a longer task than usual.
Where to start
If you're considering a custom platform migration to Shopify Plus, the first step is a discovery audit. We document your codebase, integration architecture, custom logic, data model, and redirect surface area, then return a build spec, a risk register that names undocumented system behaviour, and a fixed-price Phase 1 quote.
The dedicated custom platform to Shopify Plus migration page has more detail on our process, what's included, and how the timeline maps to your specific setup.
For broader context on Shopify Plus migrations across all source platforms, see the complete migration guide. For the operational architecture that makes a Shopify Plus migration pay back, why your Shopify Plus store needs an operations strategy and your Shopify tech stack is growing cover the layer that determines whether the new platform actually delivers.
Frequently asked questions
When does a custom platform stop scaling?
Three signals usually indicate the custom platform has hit its ceiling. First, feature velocity slows because every change requires careful regression testing. Second, the engineering cost of maintenance becomes a real percentage of revenue (above 5% is the warning threshold). Third, the original team that built the platform has moved on, and replacement engineers struggle to onboard because documentation lagged the build. If any two of these apply, migration is usually the right call.
How long does a custom platform to Shopify Plus migration take?
Most custom platform migrations run 12 to 24 weeks, with the variance driven by data unpredictability rather than catalogue size. Custom platforms have unique data structures that require custom mapping work. Migrations of brands with under 5,000 SKUs and clean data can land at 12 to 14 weeks. Brands with sophisticated bespoke logic and integration depth push to 20 to 24 weeks.
What happens to my bespoke business logic during migration?
Bespoke logic translates to one of three Shopify Plus mechanisms. Native Shopify Functions (for checkout customisation, discounts, payment routing, fulfilment logic). Shopify Flow (for workflow automation triggered by events). Custom apps and headless implementations (for logic that doesn't fit Functions or Flow). The audit phase identifies every custom logic flow and maps it to one of these targets. Most logic translates cleanly. The exceptions usually need creative architectural decisions.
Will my custom payment processing work on Shopify Plus?
Shopify Plus supports most payment processors through Shopify Payments and third-party gateways. If your custom platform processed payments through a custom integration with Stripe, Adyen, Braintree, or other major processors, the connection rebuilds against Shopify's payment system. Custom risk logic, fraud rules, and payment routing logic translate to Shopify Functions for payment customisations.
How does data migrate from a custom platform?
Custom scripts read directly from your database (PostgreSQL, MySQL, MongoDB, etc.) or APIs and write to Shopify through the Admin API and bulk operations. The complexity is in the schema translation, not the volume. Custom schemas need explicit mapping to Shopify's data model: product structures, customer fields, order line items, and any custom relationships. Plan a longer-than-usual reconciliation phase because there's no off-the-shelf migration tooling.
How much does a custom platform to Shopify Plus migration cost?
Build costs typically range from $150K to $400K, with most landing at $180K to $280K. The variance is driven almost entirely by data complexity and integration count. Brands with documented data models and clean integrations land at the lower end. Brands with undocumented bespoke logic push toward $400K. Total year-one investment including post-launch retainer usually lands at $300K to $700K.
Should I migrate or just rebuild on Shopify Plus from scratch?
Migrate. Even with custom platforms, the data has business value: customer relationships, order history, product taxonomy, and SEO authority. Rebuilding from scratch loses that. The migration scripts cost a fraction of what rebuilding from a clean slate would cost in lost SEO and customer value. The exception is custom platforms so legacy that the data is unrecoverable, but those are rare.
What's the biggest risk with a custom platform migration?
Documentation gaps. The audit phase always surfaces business logic that nobody wrote down. A pricing rule that exists only in the original developer's head. An integration nobody knows the credentials for. A workflow that was supposed to be temporary three years ago. The audit interviews engineering, ops, customer service, and finance to surface these before contracting. The risk register names them explicitly.
A Shopify Plus Agency for Strategic Design & Advanced Engineering
Building something ambitious?
- Custom platform migrations run 12 to 24 weeks. Variance comes from documentation quality, data model complexity, and how much bespoke logic needs to be re-implemented.
- The biggest hidden risk is documentation. Every custom platform has knowledge concentrated in 1 to 3 people. Migration is a chance to extract that knowledge before it leaves with someone.
- Most bespoke logic translates to a mix of Shopify Functions, Flow workflows, metafields, and apps. Some becomes custom apps. Very little needs to remain bespoke after the move.
- Data migration is the unpredictable part. Custom platforms don't have standard export formats. Custom extract scripts get written against the source database directly.
- Internal team re-orgs usually follow the migration. The platform engineers either retrain on Shopify or move into integration, data, or product roles. Plan for this conversation early.
