Migration from Horoshop and Prom to OpenCart 2.3, 3.x and 4.x

Migration from Horoshop and Prom is a module for OpenCart 2.3, 3.x and 4.x that moves the catalogue, photos, customers and order history of an old shop on Horoshop or Prom.ua into your store. The module talks to the official API of the old shop, reads the data and writes it into OpenCart. The old shop is only read — nothing in it is changed or deleted.

It is not only names and prices. Categories arrive with their nesting, products come with descriptions, sale prices, stock, SKU, barcode, manufacturer, SEO fields and photos that are downloaded into your store instead of staying as links to someone else’s server. Pro adds characteristics, variants, customers and order history.

Why a shop needs it

Moving away from a website builder or a marketplace usually looks like this: export a price list, reshape it by hand, import it, and then spend a week fixing photos, categories and stock. Customers and orders are not moved at all — they are simply left on the old platform for as long as it runs.

The module does that work itself, and repeatably. You start a run, look at the result in your own store, change the settings if needed and run it again — products are updated, not duplicated. That way the new store can be prepared calmly while the old one is still selling.

Orders deserve a separate note: they are written as history. No e-mails to customers, no stock deduction, no effect on sales statistics. The original order number, payment method, delivery and waybill are kept in the order note, so old orders can still be found by their previous number.

What the admin gets

A single page under “Extensions → Modules” with four tabs: Migration, Settings, History and Licence. On the settings tab you say where to move from, what exactly to move and under which rules.

Where the shop moves from. Horoshop — the shop address, the API login and password (in the Horoshop admin that is “Settings → Admins”, where a separate administrator for the API is added). Prom.ua — the API token from the seller cabinet and, optionally, a link to the YML export the module takes characteristics from. The password and the token are stored in the store settings encrypted.

What to move. Every block of data is switched on separately: categories, products, photos, characteristics, modifications, customers, order history. Whatever is Pro-only is labelled right in the interface, so it is clear what you get now and what comes with a licence.

Rules. Whether to update products that were already moved, whether to match existing store products by SKU, whether to publish products that are hidden in the old shop, how many records to take per request, and what quantity to set for products the old shop reports only as “in stock” without a number.

Order statuses. Five source states — new, processing, being delivered, delivered, cancelled — are mapped onto your own OpenCart statuses, so imported orders do not all end up in one bucket.

How it works, step by step

1. Read. The module calls the reading methods of the old shop’s API one by one and puts everything it received into its own staging table. Nothing is written into the store at this step, so interrupting the reading is safe.

2. Check. After reading you see counters (how many categories, products, customers and orders were found) and sample rows: how exactly the module understood a name, a price, an SKU. Errors on individual records are shown here instead of hiding in a log.

3. Write. Writing goes in batches of a few seconds rather than in one long request, so a large catalogue does not run into the hosting execution time limit. Every created record is remembered in the module’s own “source → store” map.

4. Repeat if needed. A second run finds the products it already moved through that map and updates them. If a product with the same SKU already existed in your store before the migration, the module updates it instead of creating a duplicate. Orders are never imported twice.

What exactly is moved

Categories. Horoshop sections and Prom groups become OpenCart categories with the same nesting, descriptions and SEO fields.

Products. Name, description, short description, price, sale price, availability and quantity, SKU, barcode, manufacturer, SEO fields. A special is written the way your OpenCart version understands it: in 4.1 as a product discount, in 4.0, 3.x and 2.3 as a special price.

Photos. Downloaded into your store into a folder of their own; the first one becomes the main image, the rest become additional ones. Broken links do not break the whole run: such a row is marked with an error and the migration continues.

Characteristics (Pro). Become product attributes. The Horoshop API returns characteristics as codes rather than titles — common codes are already known to the module, the rest you add as “code = Title” lines right in the settings. For Prom, characteristics are taken from the shop’s YML export.

Modifications (Pro). Products sharing a parent article in Horoshop, or belonging to one variation group in Prom, become a single OpenCart product with a “Variant” option: every variant has its own price difference and its own stock.

Customers (Pro). Registered Horoshop users and Prom clients are created without a password and without a single e-mail — the customer sets a password through “Forgot password”. If an account with the same e-mail already exists in your store, it is linked rather than overwritten.

Order history (Pro). Orders are moved with the date from the source, the products they contain, totals, discount and delivery. Stock is not deducted, sales counters are not changed, no e-mails are sent. You can also take only the orders from a chosen date onwards instead of the whole history.

Undo of a run

In Pro every run can be undone: the module deletes what that particular run created — products, categories, customers, orders, and also photos, brands, attributes and the “Variant” option, unless something else still uses them. Records the run only updated are left as they are, and whatever existed in your store before the migration is not touched at all.

The undo is tied to one run. If you made several runs, each of them has to be undone — through “History”, which shows the date, the source and the results of each.

Customers’ personal data

Customers and orders are personal data. The module only moves them between two of your own systems and sends them nowhere else — neither to CatCode nor to any third party. The seller remains the party responsible for that data, so move only as much of it as your work requires, and only if you have grounds to process it. The “Customers” and “Order history” blocks are switched off separately, so the catalogue alone can be moved without touching buyers.

Under the hood

The data that was read goes into the staging table cc_hpm_item, and the “record in the old shop → record in yours” link goes into cc_hpm_map. That map is what makes a repeated run, an undo and the binding of orders to already moved products work.

Writing goes in batches of a few seconds, returning control to the browser in between, so neither a long catalogue nor a slow old shop runs into max_execution_time. The number of records per request is configurable — lower it if the old shop answers slowly.

Connection keys are stored encrypted. The module never appears on the storefront: it is an admin tool, customers never see it, and once the move is over it can simply be switched off.

Installation

1. Upload the archive for your version. In OpenCart 4.x and 3.x — “Extensions → Installer”. In OpenCart 2.3 the installer only works over FTP, so the contents of the upload folder are copied into the shop root.

2. In OpenCart 3.x, after installing, open “Extensions → Modifications” and press “Refresh”.

3. “Extensions → Modules” → “CatCode Migrator: Horoshop & Prom” → “Install”, then “Edit”.

4. Enter the old shop’s credentials, press “Save and check connection”, choose what to move and walk through the three steps: “Read” → check the counters → “Write”.