Migrating from WooCommerce: When WordPress Stops Pulling a Catalog
Migrating your store from WooCommerce is not about products. The catalog is unloaded from the base in an evening, and the move breaks down on three other things: variations that are separate entries in WooCommerce, plugins that hold prices and shipping, and addresses that Google already knows, including tag archives. We count these three values first. The move itself takes 20–40 working days from the approval of the TK, and the shop inspection before it is free.
not the number of products, but the number of plugins with business logic
after a free audit
Price
30
Guarantee
days after project sign-off
not the number of products, but the number of plugins with business logic
The main figure of the estimate
20–40
Term of moving
working days from the approval of the TK
3-5
Analysis of the store to estimate
working days, free of charge, with the document in hand
285.9
WordPress in our dimension
ms to first byte with 119.5 KB of HTML — and no working sitemap
1,520.2
The second measured WordPress
ms to first byte - slowest of 16 sites measured
where the shop really stands: in three cards of our own portfolio, the stack did not match the dimension
What we check first
50%
Conditions
down payment, two rounds of design edits, 30 calendar day warranty
Process steps
Transparent stages with approval at every step
Total duration:20–40 days
1
Store breakdown and description of plugins
3-5 working days
We remove the volume of the catalog with variations, the list of addresses, the speed and state of the site map. In parallel, we list what each active plugin is responsible for and what is critical for orders.
2
TK and map of correspondence of addresses
3-6 working days
We fix the list of functions of the new store and sign it. Here we collect the "old address → new" table from the site map, Search Console and, if there is access, server logs.
3
Building a store on OpenCart
5-12 working days
Clean assembly, category structure, template, payment and delivery modules under the list fixed in TK. Functions that were previously provided by plugins are collected here or postponed with a note.
4
Transferring the catalog with variations
4-8 working days
Export from the database, matching attributes with the fields of the new platform, loading goods and variations. After each pass, the number of entries is compared by category, not by the total amount.
5
Redirects, integrations, test switching
3-6 working days
301 at the server level, traversal of the entire list of old addresses with response code verification, test order through every payment and shipping method on the technical domain.
6
Launch and 30-day follow-up
2-3 working days
Switching in a window with minimal traffic, the old build remains in reserve. Next is a report on crawl errors, 404 and repeated speed measurement on the same pages.
Technologies & integrations
What we build on and what it connects to
Stack
OpenCart 4.x defaults to the development branch
OpenCart 3.x — when you need a module without assembly under 4.x; we fix the version in the TK before the start
PHP and MySQL; the limit is honest: variations live in the product options, and on tens of thousands of combinations requests have to be reviewed by hand
Direct access to the WooCommerce base — more precisely, by exporting a plugin, but without access to hosting is impossible
nginx, HTTP/2, HTTPS with HSTS — the certificate encrypts the channel and does not add security to the store by itself
301-redirects at the server level are faster than the plugin, but each line must be checked with a separate request
Google Search Console is the only source of real crawl errors after switching
Integrations
LiqPay
WayForPay
Privat24
monobank
non-cash settlement
postpaid
Nova Poshta
Ukrposhta
XML feeds to marketplaces
Google Tag Manager
GA4
Google Search Console
eSputnik
What's included
Complete list of work and what you get as a result
Downloading the catalog directly from the WooCommerce base — more precisely, by exporting the plugin, which regularly loses the link between the variation and the price.
Transferring variations with the option-remaining-price link: the buyer chooses a size and sees the same availability as before.
Attributes become separate fields, rather than text in the description, and the directory filter then relies on them.
A written analysis of plugins: what we close regularly, what as a module, what we refuse. We sign the list before the start.
Address correspondence map along with archives of tags, authors and pagination - these are often forgotten when moving.
301-redirects from all index addresses with a full list run after switching, not a sample of a dozen pages.
Technical SEO of the new store: CNC, canonical, unique title, sitemap without duplicates and Sitemap directive in robots.txt.
Payment, shipping, analytics, and feed rollover with test order verification instead of "module installed" flag.
Measurements of first response, full load and HTML weight before and after - so that two numbers speak for speed, not feelings.
Control of the first 30 days in Search Console: scanning errors, 404 report and on the activation of redirects.
Transfer: access, written instructions, administration meeting with the manager. 50% down payment, two rounds of edits, 30 day guarantee.
When this service isn't right
What's not included — so there are no surprises at delivery
Transferring the blog with the entire comment history, unless you order it separately
Reproduction of the functionality of plug-ins, which have no analogues, without a separate evaluation
Guarantees of saving positions in the search
Post-launch advertising
Hosting, domain, acquiring
Who it's for
Situations where this service delivers results
Scenario 1 of 4
The catalog grew, and the administrator began to think
WooCommerce keeps each variation in a separate record, and its price, balance, and attributes in separate metadata rows. Two thousand models of five sizes are not two thousand records, but twelve thousand and several hundred thousand lines around them. The list of products in the admin goes exactly there, so it's not "WordPress that's bad" that slows down, but a specific table under a specific catalog.
We'll review your situation in a free audit
Scenario 2 of 4
Business logic is held by a dozen plugins
Volume discounts, packaging multiples, own delivery rules, exchange with the accounting system. Each extension has a separate author, a separate update cycle, and a separate annual license. As long as everything works, it's fine. The problem starts on the day when the update of one plugin breaks the checkout, and you have to roll back until the evening.
Scenario 3 of 4
The store was already crashing after the kernel update
The most common real reason for moving from those we hear: updating the site is scary, so it hasn't been updated in years. Then it ceases to be a matter of convenience and becomes a matter of safety - sooner or later a hole is found in a non-renewable assembly. Here the move is justified, and it should be counted not from the design, but from the list of functions.
Scenario 4 of 4
The pages were assembled by a constructor, and they are heavy
Elementor, Bricks, WPBakery provide fast layout and heavy HTML. On the site we measured on Bricks with WPML behind Cloudflare, the first server response is 1,520.2ms with 224.6KB of markup, and it's a non-directory page. But a nearby measurement shows the opposite: another site on Bricks delivers the first byte in 285.9ms at 119.5KB. Therefore, first the measurement, then the decision.
Migrating vs streamlining your existing WooCommerce
How this option differs from the alternative
Stick to WooCommerceOur approach
Business logicextensions from different authors, each with its own update cycle and licensestandard mechanisms of the platform plus modules, the composition is fixed in the TOR before the start
Variationsa separate entry for each variation and its own set of metadata around itproduct options in the core, the balance is carried out on combinations
Addresses in the indexnothing changes - this is the main and underestimated advantage of stayingmatch map and 301 to every old address, including tag archives
Money and timecheaper now; if the store is normal, we will write so in the audit document20-40 business days once, then upgrade without license fees
Riskan update that will once break checkout after hoursmoving in the season, so we choose the switching window according to your traffic
Free audit: we count what keeps your store
WooCommerce is rarely clean: over the years it has grown to a dozen plugins, half of which are critical for orders. The audit makes a list of them and shows what will have to be reproduced after the move.
What we measure
Plugins and business logicWhich extensions are responsible for prices, shipping, discounts, exchanges. This is the main factor in the budget and the main reason why moves fail.
The volume of the catalog and variationsHow many products and how many variations. Variable goods are transferred differently than simple ones, and the number of variations is often two to three times greater than the number of items.
Addresses in the indexHow many pages will have to be redirected. In addition to products and categories, archives of tags and authors often accumulate in WordPress - a separate category of addresses that must also be closed.
Speed to moveFirst response, full download and HTML weight - measure before to compare numbers after the move. For reference, on the WordPress site we measured, the first response was 285.9ms with an HTML weight of 119.5KB, and that's without a directory.
Site mapDoes she exist at all? On the WordPress site we measured, all three typical sitemap URLs returned 404s, and there was no Sitemap directive in robots.txt.
Update and security statusCore, theme and plugin versions. Often, this is where the real reason for the move lies — the store is scary to update.
What you get
A list of plugins with a note on what is critical for orders and what can not be ported.
A document with numbers: catalog volume with variations, addresses, speed, HTML weight, sitemap status.
Estimation of the number of lines in the map of correspondence of addresses.
Conversation for 30–40 minutes on the document.
Timeline: 3-5 business days - Plugin analysis takes longer than a normal audit
Why is it free
Because without a list of plugins, the cost of moving from WooCommerce is a guess. One plugin with its discount logic can cost more than moving the entire catalog, and both parties should be aware of this before the contract.
What's next
After the audit — the amount and term by stages with dates, contract, invoice, report. If it turns out from the numbers that it is cheaper to bring the current WooCommerce up and running, we will write that way.
Short form: your contact and site URL
Did not find your case?
Describe how it works on your side — we will tell you whether “Transferring the store from WooCommerce to OpenCart” fits and what it means in your situation. No brief and no call: one question, one answer.
Contract, act and 30-day warranty
Every project gets a written contract: scope, deadlines, amount, acceptance procedure. After delivery — act and invoice, then 30 calendar days of warranty.
Sole proprietor & bank transfer
The contractor is a registered sole proprietor. Payment by invoice with closing documents.
Rights & access — yours
Code, design and materials transfer to you after full payment. Domain, hosting, repository and analytics are registered to you.
Client portal instead of email chains
During the project you get access to a portal: contracts, invoices, acts and project status in one place.
European clients
Among our work — projects for Norway, Bulgaria, Moldova and Spain.
Verifiable numbers
Every case in the portfolio comes with a link to a live site and a technical measurement.
Audit first, then pricing
There is no price list on the site intentionally: the scope of the same work differs multiples between clients.
We say "no" when unsure
If the task isn't ours or the deadline is unrealistic — we tell you upfront.
What affects the price
Why two seemingly identical tasks are priced differently
Plugins with business logicThe main line of the estimate. One plugin with its discount system can cost more than transferring the entire catalog, because it will have to be described as TK and reassembled.
Number of variations, not productsWe count the variations separately: they are usually several times more than the items, and it is precisely on them that automatic transfers break down. We compare the number in each category before and after.
How many addresses are in the indexIn addition to cards and categories, WordPress is home to archives of tags, authors, and pagination pages. Each such address is a row in the compliance map and one redirect that someone has to check.
Where do we get the data from?Access to the base is a few days of work. Only admin without a base means plugin export and manual reconciliation of variations, and this is another volume.
What are we doing with the blog?Transfer with the structure, leave on the old domain or close with redirects - three different estimates. The decision is made at the audit, because it changes the number of lines in the address map.
Language versionsWPML and Polylang multiply addresses by the number of languages, and sometimes keep separate sets of products. A second language is not a plus ten percent to work, but another catalog to compare.
Cases
Tasks and results in numbers — all metrics measured by us
an aesthetic medicine clinic abroad is our external dimension, not our migration
Task
Check how the site actually behaves on WordPress and what will have to be restored when moving.
Solution
The speed, volume of the site and the state of the site map were taken. The volume was calculated via the WordPress open REST API: the X-WP-Total header in the /wp-json/wp/v2/pages response immediately gives the number of published pages.
Result
26 pages, first server response 285.9 ms, full load 439.4 ms at 119.5 KB - the lightest full HTML in the sample. At the same time, /sitemap.xml, /sitemap_index.xml and /wp-sitemap.xml return 404, and there is no Sitemap directive in robots.txt: the list of addresses for moving here would have to be collected in a detour. Measured on 07/31/2026.
a furniture store for the Spanish market is our external dimension
Task
Check what platform the store is actually on before considering moving from WooCommerce.
Solution
We calculated the catalog using two independent methods — a product map and an internal search — and compared the features of the platform in the markup.
Result
76 products, matching of two methods with a difference of 0, 88 addresses in the site map. The first response is 348.2 ms with 374 KB of HTML. The main thing to evaluate the move: in the portfolio card, the stack is indicated as WordPress/WooCommerce, but in fact it is OpenCart 3. We found the same gap in two more cards out of 33. Measure 07/31/2026.
a 300-item irrigation system store is a target platform dimension
Task
Show what moving to OpenCart doesn't do on its own.
Solution
We measured the speed, catalog and checkout of the store on OpenCart 3 with nginx, HTTP/2 and brotli.
Result
300 products in 40 categories on 4 levels, first response 235 ms (median of five measurements), 143.6 KB HTML and 22.5 KB in brotli, 6 delivery methods and 3 payment methods in checkout. And nearby: /sitemap.xml gives 200 with zero body, no analytics at all. The platform is useless here - no one has checked it. Measurement 01.08.2026.
What we need from you
We can't start without this — best to prepare in advance
1Access to the WordPress admin and, preferably, to the database — uploading from the database is more precisely via plugin export.
2List of active plugins; if there is no access, we will collect it ourselves during the audit.
3Access to Search Console if rights are confirmed.
4Access to hosting, DNS and domain.
5The decision we make with the blog: we move it, leave it or close it with redirects.
6One person with the right to make decisions on the structure of the directory.
If something is missing — let us know, we'll help you gather it or do it as a separate task.
FAQ
Most frequently asked questions — with concrete answers
Why go with WooCommerce at all?
Not always worth it. Valid reasons — the catalog has grown and the administration has become slow, the business logic is held by a dozen plugins that are scary to update, or the store has already crashed after updating the kernel. Bad reason - "WordPress is not for stores": Our sample has a WordPress site with a first response of 285.9ms and 119.5KB of HTML, better than half of the measured stores on other platforms. The decision should be based on your numbers.
What happens to product variations?
We transfer the option — the balance — the price while keeping the connection. This is the most delicate place: variations are usually several times more than products, and it is precisely on them that automatic transfers break down. We compare the quantity in each category separately, not the total: the total matches even when half of the sizes came to the wrong models.
I have a dozen plugins - will everything transfer?
No, and it's more honest to say it right away. Some of the functions are covered by standard means of the new platform, some by a module, and there is no analogue for some: it must be written or deliberately abandoned. Therefore, the analysis begins with a list of plugins. Without it, the estimate is a guess, and the phrase "and it should have worked too" appears at startup.
What about a blog and tags?
This is a separate category of addresses that is mentioned last. WordPress accumulates archives of tags, blog categories, authors, and pagination pages—all of which could end up in the index. They should either be moved or closed with redirects to meaningful pages. The decision is made at the audit: it directly affects the number of lines in the compliance map.
Will the store be faster?
Speed depends on page weight, server configuration and number of requests, not platform name. Therefore, we measure before and after the move: first response, full download, HTML weight. We do not name the specific percentage of acceleration before measurement. In our sample, two sites on the same builder gave 285.9 ms and 1,520.2 ms — the difference lies in the setting, not in the platform.
How long does the move take?
20–40 working days from the approval of the TK. The spread is large precisely because of plugins: a store with standard logic moves quickly, a store with its own system of discounts and exchange - for a long time. We call the exact term after the audit, when the list of functions is fixed and signed.
Will the store be unavailable during the switchover?
The new store is being assembled in parallel on the technical domain, so the work goes on without stopping sales. Unavailability is possible at the moment of switching and takes minutes, not hours; we choose the window according to your own statistics - where the traffic is the lowest. The old assembly remains raised in reserve so that there is somewhere to return to the same day.
What about customers, orders and coupons?
Clients and order history are transferred, if it is in the contract: technically, they are in the same tables as the catalog. Passwords are never transferred in a readable form - buyers restore access through mail, and this is a normal process. Coupons and accumulated bonuses depend on the plugin that calculated them: if the logic is non-standard, it falls into the same list of functions as the rest of the plugins.
Will traffic drop after the move?
Fluctuations in the first weeks are normal: the search engine has to work around the new structure. We will not promise to maintain positions, because it is not in our control zone. In our area, it's different: no old address is 404ing, the new sitemap doesn't contain duplicates, and we look at crawl errors in Search Console every week for the first 30 days. Our advice is to keep the old build up on the tech domain, closed from indexing, for a month after the move: it's the cheapest insurance you can buy.
Send access to the admin - we will count plugins, variations and addresses.
In response — a document with catalog numbers, a list of plug-ins with a criticality mark, and an estimate of work by stages. If it turns out that it's cheaper to upgrade your existing WooCommerce, you'll read this first line.
From measured cases26 pages, first server response 285.9 ms, full load 439.4 ms at 119.5 KB - the lightest full HTML in the sample
There is no price list on the site on purpose: the same work differs several times over between two clients, and a “from” figure explains nothing in that case. First a free audit — we count your pages, duplicates and speed — then we name the sum and the deadline and fix both in the contract.