Keeping operations running while switching sales channels: the ikas migration

Context

The online storefront was moving to the ikas platform, while warehouse, store, marketplace, invoicing and shipping operations would stay in our system. So the job wasn’t just moving data; it was getting two systems to talk both ways: orders created on ikas had to reach us, and status changes on our side had to reach ikas.

Problem

• Customers had to be transferred completely, along with their communication consents and addresses.
• Order history had to be visible on ikas too, but most of the old products didn’t exist there.
• If a historical order we sent to ikas came back to us as a new order, we would end up with duplicate orders and stock deducted twice.
• The bulk transfer would take days, and a deploy could cut it off halfway.

Approach

• Customers: Records were cleaned and transformed; the final run sent only new and changed customers. Addresses were added in a separate step, with province and district matching.
• Old products: Products that appeared in historical orders but were missing on ikas were reported first, then uploaded hidden from the storefront.
• Loop-back protection: Historical orders were sent with a marker; when they come back from ikas, the system recognizes and skips them.
• Resume where it stopped: The transfer status of every order is recorded; if the job is interrupted it resumes where it left off instead of starting over, and no order is ever sent twice.
• Instant status sync: Instead of periodically scanning every order, a status change on our side is pushed to ikas the moment it happens.

Lessons learned

• Some platform behaviors we could only learn by actually trying; every bulk job was first tested with a single record.
• In long-running data migrations, “resume where it stopped” has to be designed in from the start; adding it later is expensive.

My contribution

I designed and built the migration strategy and the integration, and ran the transfers step by step.