A store move is not a design move, but an address move. Catalog, customers and orders are copied by script; the risk lies in the fact that the old address of the product must return a 301 to the new one, and so on every page that Google knows. How many there are can be seen only after analysis: in the stores we measured, the site cards hold from 590 to 59,189 addresses, and in some of them the same card is repeated several times under different category paths. We do not name percentages of traffic and items after the move - this is not our area. Our zone is to ensure that no old address returns a 404 and that the new sitemap contains no duplicates. We name the price after a free audit of your store, and not according to the task description; the move itself takes 12-30 working days.
Instead of a price fork — a free audit of your store
There are no prices on this page on purpose. The scope of the move is determined not by our price, but by your current store: how many addresses are there, how many of them are duplicates, is there somewhere to automatically download the data. Until this is measured, any amount will be taken from the ceiling. That's why we measure first - free of charge and without obligation on your part.
What we measure
Catalog volumeHow many product cards and category nodes are in the store. We count using two independent methods — sitemap and cross-staff search — and show the discrepancy between them.
Site map statusHow many entries are in it, how many of them are unique addresses, is it divided into submaps, how many seconds does it take, and does it contain all the announced language versions. This number becomes the number of lines in the match map when moving.
Duplicate addressesHow many times the same card is indexed under different category paths. The four stores we measured had anywhere from no duplicates to 6.7 records per address.
Recoil speedThe first response of the server, the full HTML load and its weight are measured before the move, so that after the launch there is something to compare with, and not to argue on feelings.
Structured dataWhat types of JSON-LD does the site provide and where exactly. In our sample, there were nine types of markup, and only Organization for the entire store.
Payment and deliveryHow many payment methods and delivery services are connected now. This list will have to be recreated on the new store, and it directly adds lines to the estimate.
Analytics and Search ConsoleAre GA4, Tag Manager and pixels standing, or are rights confirmed in Search Console. Without Search Console, no one, including us, can see the real list of addresses in the index.
Technical conditionPHP version, HTTPS and HSTS, mobile viewport, redirects on the main page. Here it is immediately clear that it is not worth transferring from the current site.
What you get
A document with numbers: the volume of the catalog, how many addresses in the site map and how many of them are unique, the first response of the server and the weight of HTML, a list of connected payment, delivery and analytics systems.
List of findings that should be corrected when moving, and not taken to a new store: duplicate addresses, language branches outside the site map, outdated software versions.
The estimate of the number of rows in the future address mapping is the main driver of the migration estimate.
A conversation for 30–40 minutes, where we go through the document point by point and answer questions.
Timeline: 2-4 business days from when we receive the site address
Why is it free
Because without it, we cannot name a fair amount. The migration estimate is based on one number - how many addresses will have to be transferred and redirected - and it can be taken only by measuring: we count the addresses in your site map and cross-check the standard search of the store. No one, including us, can see the full list of addresses in the index without access to Search Console, so we do this reconciliation already in the project, when access is available. Calling a plug to measure would mean either to be safe and overestimate, or to underestimate and then rewrite the estimate. The audit is cheaper for us than both options. You are not to blame for this: the document is yours, even if we will not do the moving.
What's next
After the audit, we name the cost and term by stages with calendar dates, not the range. Next, the contract, the bill and the certificate of the completed works — we work officially, in particular with customers from the EU. If it becomes clear from the numbers that you do not need to move now, we will say so: four such cases are listed below on this page.
Short form: your contact and site URL
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
How many addresses are in the indexThis is the main figure of the estimate. In measured stores, sitemaps hold from 590 to 59,189 addresses — and that's how many lines should be in the compliance map.
Status of addresses on the old siteIf the product is available under several category paths, each path must be closed with a redirect. We saw 3,971 records for 590 unique addresses: in this case, the map of compliance has to be built not from the sitemap, but from logs and Search Console.
From which platform is the moveExporting to CSV or accessing the database is a matter of days. A non-export platform means collecting data from a storefront, and that's a different amount of work and a different budget line.
The volume of data, except for the directoryCustomers, order history, reviews, blog articles. Each data type is a separate migration script and a separate reconciliation of the before and after quantities.
Does the domain change?Moving within the domain is a standard scheme. Changing your domain adds another layer of redirects and a longer tracking period in Search Console.
Number of language versionsEach language has its own set of addresses and its own branch in the sitemap. In the three measured stores, only one of the two language versions made it to the sitemap, and the second was simply not available for search.
Who it's for
Situations where this service delivers results
Scenario 1 of 4
You are sitting on a platform with a subscription fee and want your website
The main question of the move is not how to move the goods, but what will happen to the addresses that Google already knows. The answer is provided by the correspondence map: the line "old address → new" for each page from the site map and from the Search Console. Without this list, the move turns into a lottery, and with it - into a technical procedure.
We'll review your situation in a free audit
Scenario 2 of 4
The store is on an old engine that is no longer being updated
The core was controlled by hand, the modules conflict, it is impossible to update. Then it's cheaper to put together a clean build and migrate the data than to fix what's there. The decision is made after reviewing the files and the database: this is not visible from the screenshot of the admin, and a mistake here is worth double the work.
Scenario 3 of 4
The domain is the same, the engine is different
The most common scenario and the safest: the domain keeps its history, only the address structure changes. Redirects are compiled into an nginx map file and checked with a full list before switching, not selectively after complaints.
Scenario 4 of 4
You have already accumulated duplicate addresses
Moving is an excuse not to drag them along. In the garden equipment store, we recorded 33,493 sitemap entries at 8,690 unique addresses: each product is indexed under several category paths. Transferring such a structure one-to-one means transferring the problem.
What's included
Complete list of work and what you get as a result
Pre-move inventory: how many addresses are in the sitemap, how many of them are unique, what Search Console knows
Address correspondence map: an "old → new" string for each page that exists in the index
301 redirects in the nginx map file with a full list check instead of a selective one
Transferring customers and order histories while retaining IDs
New sitemap without duplicates: one sitemap - one canonical address
Switching in a window with minimal traffic, the old site remains in reserve
Post-move control: crawl errors in Search Console, 404 report and redirects
TTFB measurements and HTML weights before and after — so that the move does not turn out to be a step backwards
Transfer: access, instructions, passing the admin with your manager
When this service isn't right
What's not included — so there are no surprises at delivery
Guaranteed items and traffic after the move: this is not promised by anyone who works honestly
Redesign: Migration moves data, look and feel is a separate job and a separate budget
Filling the cards with things that were not on the old site
Hosting, Domain, SSL
Rewriting content that was not unique before the move
Process steps
Transparent stages with approval at every step
Total duration:12–30 days
1
Inventory and audit of the current store
2-4 working days
We count addresses in the site map and unique addresses among them, remove Search Console data, view files and database. The output is the number from which the estimate is calculated.
2
Map of correspondence of addresses
2-5 working days
Table "old address → new" for each page from the index. Here we decide which duplicates we do not transfer, but reduce to one canonical address.
3
Building a new store on OpenCart
4-10 working days
A clean build with the necessary payment and delivery modules, category structure and CNC for the new address scheme.
4
Data transfer and quantity reconciliation
2-5 working days
Products, categories, attributes, images, customers, orders. After each transfer, the number of records before and after is compared.
5
Redirects, test switching, running through the list
1-4 working days
301-redirects in the nginx map file, running through the entire list of old addresses with a check of response codes, test switching on the technical domain.
6
Launch and monitor in Search Console
1-2 working days
Switching in a window with minimal traffic, the old build remains in reserve. Next is the scan and 404 error report.
Did not find your case?
Describe how it works on your side — we will tell you whether “Migration of the online store to OpenCart” fits and what it means in your situation. No brief and no call: one question, one answer.
Cases
Tasks and results in numbers — all metrics measured by us
garden equipment and spare parts store — our external technical dimension, migration not performed by us
Task
Calculate how many addresses would have to be transferred when changing the platform: this is the measurement of the operating store as of 07/31/2026, not the case of relocation.
Solution
We disassembled the site map into sub-maps and checked each one in fact: page 1 — 3,000 addresses, page 10 — 3,000, page 19 — 1,321.
Result
55,321 product pages and 3,868 categories — 59,189 addresses together. The compliance card should contain the same number of lines when moving. The first response from the server at this volume is 840.5 ms, the full HTML download is 997.4 ms.
professional tool shop is our external technical dimension
Task
Estimate how many addresses in the site map are duplicated, that is, how many extra lines would be involved in a "one-to-one" move.
Solution
We counted entries in the site map and unique addresses among them, compared them with language branches.
Result
25,537 records for 6,857 unique addresses: each product is indexed an average of 3.9 times under different category paths. At the same time, all the addresses in the site map belong to one language version, although the site gives another by default. Sitemap takes 34.2 seconds.
the spice and seasoning shop is our external technical dimension
Task
Calculate the real volume of the index on a small directory: how many of the sitemap entries are truly unique.
Solution
We disassembled the site map and reduced the records to unique addresses, separately checked language branches.
Result
3,971 entries in the site map for 590 unique addresses — about 580 products and 7 categories. All 590 addresses lead to one language version, the second is not in the sitemap at all, although it is declared in hreflang. TTFB 428.4 ms at 264.1 KB HTML.
medical supplies store with content part is our external technical dimension
Task
Show what a sitemap looks like that doesn't cause problems with moving: a counterexample to the previous three.
Solution
We checked the site map, compiled as an index from four files — main, categories, products, information pages.
Result
96 products and 21 categories — exactly 123 addresses, no duplicates. The compliance map for such a store is 123 rows, not thousands. TTFB 440.7 ms at 103.2 KB HTML.
Technologies & integrations
What we build on and what it connects to
Stack
OpenCart 4.x is set by default
OpenCart 3.x — when you need a module that is not yet available under 4.x
PHP
MySQL
nginx (301 redirects in the map file)
Cloudflare
ocmod
Integrations
Google Search Console
Google Analytics 4
Google Tag Manager
Nova Poshta
LiqPay
WayForPay
monobank "Purchase in installments"
Rozetka site
Transfer to your OpenCart vs. staying on the paid platform
How this option differs from the alternative
Subscription platformOur approach
Platform feemonthly, growing with catalog and trafficno, just hosting and domain
Address structureset by the platform, control nothingyours, changes for SEO tasks
Customer baseaccess within the limits permitted by the platformin your database, export at any time
Modifications for your processesonly what is in the settings or APIany: the code is open
Riskzero until the platform changes the rules or ratesone-time relocation risk: compliance map and 301 redirects
What we need from you
We can't start without this — best to prepare in advance
1Access to the current site: files, database or at least catalog export - without this, the scope of the move cannot be estimated.
2Access to the Search Console: it is there that you can see the real addresses that the search knows, and not just those that are in the sitemap.
3The address of the current sitemap, if there is one, and the answer, whether it is registered in robots.txt.
4List of data to be transferred in addition to the catalog: customers, orders, reviews, blog.
5Access to the hosting and domain where the new build will live.
6One person on your side who will confirm the switching window and be in touch on launch day.
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
Will I lose traffic after moving?
Honest answer: no one gives guarantees here. We are responsible for the technical part — that each old address from the index returns a 301 to the corresponding new one, that the new sitemap does not contain duplicates and that the canonicals are correct. What the search will do with it and for how long is not our area, and to promise interest here would be to sell something that we do not control.
How much does migration cost and what does the amount depend on?
There is no fork on this page on purpose, and this is not a way to avoid the answer: the amount is set by your store, not our price. The main factor is the number of addresses that will have to be transferred and redirected: in the sitemaps we measured, it is from 590 to 59,189. The second is the state of these addresses: if the product is available under several category paths, each of them must be closed with a redirect. The third is from which platform is the move and whether there is machine export from it. To calculate these three things, we do a free audit in 2-4 working days, give a document with numbers, and only then name the cost and term by stages.
How long does the move take?
12-30 working days. Schedule: inventory and audit days 2-4, address match map 2-5, new store build 4-10, data migration and reconciliation 2-5, redirects and test switchover 1-4, launch and monitoring 1-2. The longest stage is the assembly, the most responsible is the correspondence map: it is at this stage that the relocations break down.
What is an address matching map and why is it there?
This is a table where there is a new one for each old address from the index. It is done before the move, not after. The sources are the sitemap of the old store, Search Console reports and server logs. Next, these pairs are turned into 301 redirects in the nginx map file, and before switching, we run through the entire list and check the response codes. Selective verification does not work here: 404 is exactly where you did not look.
Are customers and order history transferred?
Yes, together with identifiers, so that the story remains tied to the person. After each transfer, we compare the number of records: how many were in the source, how many were in the new database. At the same time, passwords are not transferred in a readable form - clients are put through a recovery procedure, and this is a normal practice, not an inconvenience.
And if I have duplicates in the sitemap, should I transfer them?
No. Moving is the best time to remove them. We reduce each card to one canonical address, and close the rest of the paths with a redirect to it. To give you an idea of the scale: the garden equipment store had 33,493 records for 8,690 unique addresses, the tool store had 25,537 for 6,857, the spice store had 3,971 for 590. Moving this one-to-one means moving the problem to a new site.
What platforms are you porting from?
Technically, from anywhere where there is export of the directory or access to the database. Practically everything boils down to this: with a normal CSV or access to the database, the transfer takes several days, without them you have to collect data from the storefront, and this is another volume of work. In the portfolio that we measured, there are no completed migrations from specific platforms, so we will not promise that "we have already transported hundreds of these".
When is it better to switch sites?
In a window with minimal traffic, with an old assembly in reserve and with a ready list of redirects that have already been driven away. Immediately after the switch, we look at the response codes on a sample of addresses and the scan error report in Search Console. If something goes wrong, a rollback is a DNS or config rollback, not a crash development at night.
What about payment terms and warranty?
We work officially: a contract, an invoice, a certificate of completed works, including with customers from the EU. Advance payment of 50% at the start, the rest — after acceptance before switching. Two rounds of edits are included in the price if they are within the approved scope. Thirty calendar days after acceptance, we correct errors free of charge on our part (warranty period according to the contract), including redirects that turned out to be inaccurate. The sum in euros named after the audit is fixed for 14 days, hryvnias are calculated at the NBU exchange rate on the day of invoicing.
Which version of OpenCart are you migrating to, 3.x or 4.x?
By default on 4.x: Relocation is the most convenient time to be on the branch being developed so you don't have to migrate a second time in a year. We are talking about one "but" before the start, and not in the middle of the work: the four rewrote the event system, and part of the Ukrainian modules - payment, delivery, price upload - so far only has an assembly for 3.x. Therefore, the list of your modules and integrations is included in the inventory before the move: everything critical has an analogue under 4.x — we transfer it to 4.x; there is no module for the four yet - we discuss 3.x at the start and fix it in the TK together with the terms of the future update.
Give the site address - in 2-4 working days we will return with a document: how many addresses are in your site map, how many of them are duplicates, how the catalog is given and what should not be taken to the new store.
From measured cases55,321 product pages and 3,868 categories
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.