Signs the platform costs more than the code
The first sign is the number of plugins holding up functionality that should be part of the shop. A WooCommerce install with 34 active plugins, seven of which touch cart and shipping, already is a custom system, only assembled from other people's parts and without tests. Every WordPress update becomes an event rather than routine.
The second is the cost nobody adds up. Shopify Plus at PLN 1.5 million monthly revenue is around USD 2,300 in subscription, plus USD 400 to 900 of apps, gateway fees and a paid theme. The annual total can pass PLN 200,000 before you count agency hours spent working around platform limits. That does not automatically make custom cheaper, but it does mean the comparison is worth running.
The third sign is the hardest to argue with: something on the roadmap the platform simply will not do. A configurator pricing eight parameters, contract pricing per B2B account, an installation booking system, made-to-measure ordering. If the answer to those requests has been that is not possible for six months, you are already paying for it, just not on an invoice.
- More than 25 plugins, several of which modify cart or checkout
- Subscriptions and apps totalling PLN 8,000 to 10,000 a month
- Category TTFB above 600 ms despite caching and better hosting
- Recurring update conflicts that force a rollback
- A roadmap item the platform cannot support without rewriting checkout
Headless is not the same as custom
At least three different projects go by the name migrating to Next.js, and they differ in cost by an order of magnitude. The first is a Next.js storefront on the existing backend: Shopify Storefront API, or WooCommerce over REST or GraphQL, with checkout left on the platform. You get speed and full control over the front end and content structure without touching the riskiest part of the system. Typical delivery is 8 to 14 weeks.
The second is a custom storefront on a commerce engine such as Medusa, Saleor or commercetools. Here you take on cart and checkout, so payment gateways, carriers and tax logic come with it, but you are not writing catalogue or order management from scratch. This is the most common sensible destination for a retailer turning over PLN 5 to 40 million a year.
The third is a full application built around a specific selling model. It makes sense where the shop is really a system: made-to-measure, configurators, complex B2B pricing, integration with production. It costs the most and requires a team that stays after launch. If you cannot name the person responsible for that code in two years, pick one of the earlier options.
The parts of the estimate everyone underprices
Checkout is not a form. It is gateway error handling, payment retries, partial stock availability at the moment of payment, mutually exclusive discount codes, mixed VAT rates in one basket, parcel locker selection with a map, and address validation. On the projects we have run, checkout with proper edge-case handling accounts for 25 to 35 per cent of the build budget.
The second underpriced layer is operational integration. Order management middleware or a direct ERP connection, invoices and credit notes, returns and exchanges, carrier labels, shipment statuses, stock synchronisation every few minutes, phone orders. None of it looks impressive on a design mockup, and all of it determines whether the customer service team can work after launch.
The third is everything marketing depends on. The Merchant Center feed with custom labels, the analytics data layer, the reviews platform integration, segmented newsletters, and landing pages that can be edited without a developer. Skipping that last point is a common mistake and ends with every campaign requiring a production deployment, which is why a custom build almost always comes with a headless CMS for content.
SEO migration: URLs, redirects, reindexing
Migrations break on URLs more often than on anything else. The rule is simple: if the current structure has no serious flaw, keep it character for character. Changing the category scheme while rewriting the front end is two risky operations at once, and if traffic drops you will not know which one caused it. When a change is unavoidable, build a one-to-one map rather than a blanket redirect to the homepage.
Before launch we crawl the old site fully with Screaming Frog, export every URL returning 200, and join that against the URLs that earned traffic in Search Console and analytics over the past twelve months. That is the checklist. After launch, the same crawl against the new site must return either a 200 or a 301 to an unambiguous equivalent for every entry.
A realistic expectation after a large migration is four to eight weeks of visibility wobble even when the work is correct, because Google has to recrawl and reprocess everything, and on a 30,000-URL store that takes time. Launching during peak season is a mistake that costs more than the migration itself.
- A full pre-launch crawl plus twelve months of traffic-earning URLs as the checklist
- A one-to-one redirect map, with no blanket redirects to category pages
- Structured data parity: product, offer, reviews, breadcrumbs
- 404 monitoring with alerting from the first hour after launch
- A launch date outside peak, at least six weeks before the season starts
Ship it in slices, not in one night
Rewriting the whole shop and cutting over in a single night is the most expensive way to discover what nobody anticipated. What works better is letting the new front end take traffic in slices: blog and information pages first, then product pages, then listings, with checkout staying on the old system until last. A proxy at the CDN routes paths to the right application, and any step can be reverted in a minute.
When taking traffic, use a percentage split rather than a full switch. Ten per cent of traffic on the new product pages for three days will surface bugs no test caught, at a scale that does not threaten revenue. As a bonus you get a conversion rate comparison between old and new on identical traffic, which is instructive and not always flattering.
When we talk clients out of it
Below roughly PLN 3 million in annual revenue, a custom store rarely pays back within three years. The subscription savings will not cover build and maintenance, and the team's attention shifts from marketing to technology. In that bracket, a solid theme, a clean product feed, decent analytics and steady conversion work return far more.
We also advise against it when nobody will own the system after handover. A custom store is a commitment: dependency updates, monitoring, on-call cover during sales peaks, fixes whenever a carrier or gateway changes its API. If the plan ends at the word launch, in eighteen months the project will be in worse shape than the WooCommerce install you left. Model the three-year total cost including maintenance and compare it against the subscription stack; the decision usually becomes obvious in one direction or the other.
Key takeaways
- Migrating to Next.js describes three different projects that differ in cost by an order of magnitude.
- Checkout and operational integrations are half the budget, not an afterthought.
- Keep the URL structure unless there is a serious reason to change it.
- Take traffic in percentage slices and migrate checkout separately.
- Under about PLN 3 million in annual revenue a custom store usually does not pay back.
Common questions
A storefront on the existing backend, with checkout left on the platform, is typically PLN 60,000 to 140,000 and 8 to 14 weeks. A full move to a custom engine with checkout, payments and ERP integrations usually starts around PLN 250,000. Add annual maintenance of roughly fifteen to twenty-five per cent of the build budget in either case.
A short-term wobble of four to eight weeks is normal even on a well-executed migration, because Google has to reprocess the whole site. Lasting drops almost always trace back to redirect errors, lost structured data, or a URL structure change without a one-to-one map. Launching outside peak season and monitoring 404s from the first hour keeps the risk manageable.
Very often, yes. You keep a proven checkout, payment handling and an admin the team already knows, while gaining control over design, performance and content structure for SEO. The limit is the platform's rules around cart and promotions, so if your pricing or discount logic is unusual, this option runs out quickly.