Transferring the online store to OpenCart

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.

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.

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.

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.

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.

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.

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".

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.

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.

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.