Most articles about online stores end with "and there you go, you are live". In reality that is where the interesting part begins: PHP versions change, partners update their APIs, the catalogue grows from 500 products to 6,000, and the sales team still tracks orders in a spreadsheet.
This article is about what happens after launch. If you are still planning your store, start with the complete OpenCart development guide or the platform comparison.
Why an OpenCart store is never "build it and forget it"
OpenCart is a stable platform, and that is exactly the trap: a store can run for years without visible breakage while quietly accumulating problems that then surface all at once.
- The environment moves. The host upgrades PHP and half of the extensions written for 7.4 stop working. An unprepared upgrade turns the store into a white screen.
- Partner APIs are versioned. Carriers, payment gateways and marketplaces change formats and retire old versions. An extension installed three years ago simply stops creating waybills one day.
- The catalogue grows. What felt instant with 500 products takes 3–5 seconds per category page once you have 6,000 items behind filters.
- Security. OpenCart is popular, so it gets scanned at scale. Nobody is looking for a flaw in your store specifically — they are looking for it in an outdated extension installed in thousands of stores.
What maintenance covers
1. Updates and security
The main source of trouble is not the OpenCart core but third-party extensions — that is where SQL injections and unrestricted file uploads usually live. What we do:
- update the core and extensions on a copy of the site first, never straight on production;
- remove extensions the author no longer maintains, or reimplement what they did;
- move the admin panel off its default path, enable two-factor authentication and IP restrictions;
- audit upload directories for stray PHP files — the classic web shell arrives through an upload form;
- keep HTTPS and security headers current.
2. Backups that actually restore
A backup you have never restored is not a backup, it is a hope. The working minimum: a daily dump of the database and files, stored off the same server, plus a quarterly test restore onto a separate domain. That is the only way to learn the archive is not empty before you need it.
3. Speed
Catalogue speed is revenue — it affects sales directly. On large catalogues the simple things usually win:
- indexes on
product_description,product_to_category,product_attribute— without them every filter scans the whole table; - caching categories and menus so each click does not rebuild the tree;
- WebP images and lazy loading — on a product page with 15 photos that is tens of megabytes;
- disabling extensions kept "for later" that still execute on every page;
- pruning session and log tables, which grow to gigabytes on a live store.
4. Small changes and bug fixes
This is what maintenance is really for: add a field to the checkout form, fix a promo banner layout, change delivery rules before the holidays. Estimating each of these separately takes longer than doing them, so they are handled within a monthly retainer.
5. Monitoring
The store should report a failure before the customer does. The minimum worth having: uptime, order creation errors, payment failures, failed calls to the carrier and the CRM. Separately — an exchange log for external systems, without which diagnosis becomes guesswork.
When a store needs a CRM
The OpenCart admin manages orders, not customer relationships. It does not know the customer has already been called twice, will not remind anyone to follow up next week, and will not show how many orders are stuck in processing. Signs it is time to move on (more detail in "When your business needs a CRM"):
- orders are handled in email, a spreadsheet and a messenger at the same time;
- a manager cannot recall what was promised last week, and the correspondence sits in a personal inbox;
- nobody can quickly say how many orders have been "in processing" for more than three days;
- repeat sales never happen, because the customer base exists only as a list of orders;
- website stock and warehouse stock disagree, and you hear about it from a customer.
What to sync between the store and the CRM
"Integrate with a CRM" is too vague. In practice it is several separate data flows, each with its own direction and frequency:
- Orders: OpenCart → CRM. Immediately on checkout, with line items, totals, comments and the UTM source.
- Statuses: both directions. A manager changes the status in the CRM and the customer sees it in the store. This is the most common source of confusion, so status mapping belongs in a lookup table, not hard-coded.
- Customers: OpenCart → CRM with deduplication by phone and email. Without it the database turns into three records for one buyer within six months.
- Products and prices: ERP or CRM → OpenCart. Prices almost always live in the accounting system; the store only displays them.
- Stock: warehouse → OpenCart. The most critical flow. Selling something you do not have costs more than any other integration mistake.
- Waybills and payments: CRM → OpenCart → customer. The tracking number should reach the buyer without a manager in the loop.
How it is built
The difference between an integration that runs for years and one that needs weekly nudging comes down to four things.
- A queue instead of a direct call. If the store calls the CRM synchronously at checkout, a CRM outage means a lost order and an error on the customer's screen. The right way: push the event onto a queue, confirm to the customer immediately, and run the exchange in the background with retries.
- Idempotency. Every order carries an external identifier, so a repeated send updates the existing record instead of creating a duplicate. Without it the first network hiccup produces two identical orders.
- An exchange log. What was sent, when, what came back, how many attempts. This is not a nice-to-have — without it "why did this order not arrive" has no answer.
- Scheduled exchange where it fits. Stock and prices do not need real time: syncing every 5–15 minutes puts a fraction of the load on both systems compared with pushing every single change.
Technically we build the exchange over the OpenCart REST API or a custom module exposing a dedicated token-protected endpoint. For complex cases we add an intermediate Laravel service that holds the queue, the field mapping and the log — so the store and the CRM never need to know about each other.
Systems we integrate most often
- KeyCRM — popular in Ukrainian e-commerce, with a sane API and built-in carrier and fiscal receipt support. The fastest start for a store that simply wants to handle orders properly.
- Creatio — a Ukrainian enterprise-grade platform: deals, contacts, pipeline and processes, for companies that have outgrown simple order handling.
- OneBox — a Ukrainian system where CRM and accounting live together; handy when you would rather not maintain two separate databases.
- Perfectum — a Ukrainian solution for service businesses, with the option of self-hosting.
- HubSpot, Pipedrive, Zoho — when the point is the sales pipeline and how the team works leads, not accounting.
- Ukrainian accounting systems (Debet Plus, Master:Accounting, ISpro) — products, prices, stock, invoices. Usually a two-way scheduled exchange through an intermediate service.
- Industry-specific systems — wherever a usable API exists.
- A custom CRM on Laravel — when off-the-shelf systems do not fit the process and you end up bending the business around the software instead of the other way round. Integration is then the easy part: we write both sides.
Functionality a store actually needs
The list of things most often added after launch. Anything missing here is your next maintenance task:
- search that tolerates typos and keyboard layout, not just exact matches;
- filters by attributes (power, size, brand), not only by category;
- one-step checkout without forced registration;
- carrier branch selection with search and city autocomplete;
- online payment alongside cash on delivery — in Ukraine dropping the latter costs you a share of orders;
- order status and tracking number available to the customer without calling anyone;
- notifications on every status change — email, SMS or messenger;
- marketplace feeds (covered in detail in the OpenCart integrations article);
- GA4 with e-commerce events, so decisions rest on data;
- an admin panel a manager can work in quickly: bulk actions, sensible filters, price import.
Common mistakes
- Editing the core instead of using ocmod/vqmod. It works right up to the first update, which erases every change.
- "Real-time" sync with no queue. The first CRM outage takes orders down with it.
- No customer deduplication. Six months later there are three records per person and no usable analytics.
- Stock synced once a day. Enough to regularly sell what is not in the warehouse.
- Marketplace extensions chosen on "it works". The author disappears, the source is a maze, updating is impossible — and you find out exactly when it is urgent.
- No staging environment. Every change straight on production; it is only a matter of time before that means downtime.
Where to start
If the store is already running but the picture is unclear, start with an audit: versions and vulnerabilities, the state of extensions, catalogue speed, existing integrations and their logs. The result shows what needs fixing now and what can be planned.
We provide support and maintenance for OpenCart stores and our own CMS, as well as e-commerce development from scratch and CRM integrations built around your actual process. If you want to understand what is going on with your store, get in touch and we will look at it together.