Moving a store from WooCommerce to Payload
Not because the site was slow. Because the amount of specific functionality kept growing, and every new capability meant working around the limits of someone else's platform. We moved to our own system where the store and CRM are one whole.
The reason for the move wasn't speed. The site worked, and it could have been sped up further. The problem was different: the store had accumulated a lot of specific functionality — its own, not "like everyone else's". And the more of it there was, the more often each new capability required not building, but working around: another plugin, another field on the side, another crutch on top of someone else's logic.
On top of that, the store lived in a "site separately, CRM separately" setup. Orders, customers, statuses, shipments — all of it had to be kept in sync between two systems that know nothing about each other.
At some point the math became obvious: it's cheaper to build a system for these processes than to keep paying to work around someone else's limits. That's how the store and the CRM became one whole.
What was needed
A store with a lot of its own logic, several suppliers with different terms — and managers working full-time inside the system.
- Move a catalog of 10,000+ products without losing search positions
- Merge the site and the CRM into one system instead of two that have to be synchronized
- Connect suppliers and update their price lists without manual work
- Account for each supplier having their own shipping days and their own delivery methods
- Work with both own stock and dropshipping in one catalog
- Keep the ability to keep growing its own functionality — without workarounds
What we did
A custom system on Payload CMS and Next.js: the store's logic is written in code for specific processes, not assembled from other people's plugins.
- A catalog of 10,000+ products with color variants in one card instead of separate products for each color
- More than 13 thousand old addresses are redirected to new ones automatically — positions preserved
- A CRM inside the site: orders, customers, statuses and shipments in the same system as the store
- Connecting a supplier is a setting, not development: feed format, address, update interval and column mapping
- Price lists update on a schedule by themselves: price, promotional price and availability; products that are no longer in the feed are taken off sale by the system
- Each supplier has their own delivery methods and their own shipping schedule — the product card itself calculates when the parcel will leave
- Payment by card, cryptocurrency and cash on delivery; delivery by Nova Poshta and Meest
- Waybills are created automatically, parcel statuses are pulled in on their own, and the customer gets an SMS
- A loyalty program, login by phone number, reviews, IMEI check, export to Google Merchant
Separately about the move. A store with such a history can't simply be "moved": over the years it has accumulated page addresses by which it is found in Google. So every old address leads to its own new one — there are more than thirteen thousand such redirects.
At the same time we fixed what had been getting in the way for years: previously each product color was a separate card, and they competed with each other in search. Now colors are variants of one card, and the buyer switches between them on the spot.
The most interesting part turned out to be the suppliers. Previously, updating prices and availability was manual work: download a price list, verify, update. Now a supplier in the system is just a card with settings: the file format (CSV or XML), the price-list address, how often to fetch it and which column means what.
Then the system does everything itself on a schedule: it fetches the price list, updates prices, promotional prices and availability, and takes products the supplier no longer has off sale. Every run is written to a log — you can see how many items were updated and what exactly happened.
It's important that suppliers differ. Each has their own shipping days and a cutoff time to order by, and their own available delivery methods. All of this is set in their card, and the buyer on the product page sees not a generic phrase but something specific: when exactly this particular product will ship. Thanks to this, the store works equally calmly with its own warehouse and with dropshipping suppliers — in one catalog, without separate sites and spreadsheets.
The admin panel is built for the manager's work, not for what the platform allows. The main screen has a sales chart and quick links to what is needed every day. In the header — the SMS balance, so a mailing doesn't stop in the middle of the day, and notifications about new orders.
In an order the manager sees everything at once: the order contents, the payment status, the button to create a waybill and the SMS status for the customer. A supplier's price list can be uploaded manually by specifying which column is for what — and you can immediately look at the log of what exactly was updated.
But the main thing is that the system is open to growth. The next specific business requirement is a development task inside your own system, not a search for and development of a plugin that "roughly" does what's needed.