Automate Now or Replatform First? How to Sequence the Two Without Paying Twice

Ask one question of each workflow. If your platform disappeared tomorrow and a different one took its place, would this work still exist? If it would, automate it now. If it would not, wait for the move. You can run the test in ten minutes. Write down every recurring admin task that costs more than an hour a week. For each one, name the systems it touches. If the task is a handoff between two systems that will both still be there after a replatform, such as an inbox, an accounting package, a supplier, or a spreadsheet, it is platform-independent. If the task is manipulation of data that only exists inside the platform, such as product records, category structure, or theme logic, it is platform-dependent. Some workflows are mixed, and those are the interesting ones. A supplier price update that reads a spreadsheet, matches products and writes new prices into the store has a portable half and a disposable half. The matching and approval logic is portable. The write step is not. Build the portable half properly and keep the write step deliberately thin.

Anything that reads or writes the platform's own data model should wait for the replatform. Product records, category structure, on-site merchandising rules, checkout flow, discount logic, tax rules and shipping rates do not survive a platform change, and automation built against them does not either. This is not a guess about how migrations behave. It is how they are scoped. Migration tooling moves products, variants, categories, customers and order history. What it does not move is configuration. Tax rules, shipping zones and shipping rates are configuration rather than data, and they are rebuilt by hand on the destination platform. Anything implemented as a plugin or as custom code, including subscriptions, loyalty schemes and product customisers, is also rebuilt rather than moved. URL structure is the sharpest version of this. Shopify forces `/products/<handle>` and `/collections/<handle>` path prefixes, so a merchant coming from a platform with a different structure cannot achieve one-to-one URL parity and needs a full redirect map instead. Automation that depends on your current URL shape, category tree or internal product identifiers is automation with a known expiry date. There is more detail on what breaks in the Neto to Shopify migration guide.

Work that sits between systems survives a replatform almost entirely. Copying orders into accounting, chasing suppliers for delivery dates, answering the same customer email forty times a week, moving stock figures between an online store and a separate back-office system: none of it changes character when the storefront changes. The reason is that these workflows are defined by the counterparty, not by the platform. An automation that watches an inbox for supplier confirmations, pulls out the promised dates, updates the purchase order and replies is shaped by what a supplier email looks like. Change the storefront underneath it and the supplier still writes the same email. The counterparty changes eventually, the pattern does not. That makes the rebuild cost after a move small and predictable. A workflow with one platform-facing lookup needs one connector rewritten. A workflow with logic spread through platform templates and plugins needs the whole thing rewritten. This is the same reason the join between your tools is usually a person: the joins are where the manual labour concentrates, and they are also the most portable part of the stack.

Classify your own list against this table before you commit any budget. The right-hand column follows directly from the middle one, which is the whole point of the test. | Workflow | Where it lives | Survives a replatform | Verdict | |---|---|---|---| | Copying orders into Xero or MYOB | Between systems | Yes, one connector changes | Automate now | | Answering repeat customer enquiries | Inbox, outside the platform | Yes | Automate now | | Chasing suppliers for delivery dates | Email and purchase orders | Yes | Automate now | | Quote and abandoned order follow-up | Email and CRM | Yes | Automate now | | Reconciling stock counts against a spreadsheet | Between systems | Mostly, the read step changes | Automate now, keep the connector thin | | Bulk product data enrichment and edits | Inside the platform | No | Wait for the move | | Category and collection structure | Inside the platform | No, URL structure changes | Wait | | On-site merchandising and search ranking | Inside the platform | No | Wait | | Checkout, discount and promotion logic | Inside the platform | No | Wait | | Tax rules and shipping rates | Platform configuration | No, rebuilt by hand | Wait | | Marketplace listing and inventory sync | Platform-native on some platforms | Depends entirely on the destination | Wait until the destination is chosen | The top half of that table is where the recurring hours usually are. Owners tend to look at the bottom half first, because that is the part of the business the platform demo talked about.

Replatforming timelines slip, and the admin burden runs for the whole slip. Bloor Research puts average cost overrun on data migration projects at roughly 30 per cent and average schedule slippage at roughly 41 per cent, with more than 80 per cent of projects running over time, over budget, or both. Two caveats on those figures, because they matter. Bloor's work covers enterprise data migration generally rather than e-commerce replatforming specifically, and the publication year could not be confirmed, so treat them as directional rather than as a forecast for your project. The direction is enough. Roughly 41 per cent slippage on a six month plan is closer to eight and a half months, and that is measured from the day the project actually starts rather than the day you decided you wanted it. In practice a move you believe is six months away is often eighteen. Put a number on that. Hours a week of manual admin, multiplied by a realistic hourly cost, multiplied by eighteen months, is the cost of the wait. If that figure is material, then deferring automation is a decision to spend money, not a decision to save it. Very few replatform business cases include that line.

Wanting more value from a platform you already pay for is sound commercial thinking, not a mistake to be talked out of. The failure mode is not the instinct. It is spending the automation budget on the part of the stack that is scheduled for demolition. The instinct is correct about the size of the sunk commitment. Neto lists Essential at $199 a month AUD and Professional at $789 a month AUD excluding tax, with add-ons such as Neto Inventory at $199 a month and each extra sales channel at $99 a month. Shopify's published Australian pricing runs from $56 a month on Basic to $575 on Advanced, with Plus starting from $3,700. A merchant paying near the top of the first list is right to ask what more that spend could be doing. The reframe is small but decisive. The instinct is about return on money already committed. Automating platform-internal work does the opposite of that: it adds new spend to an asset with a known end date, and the return stops when the asset does. Point the same instinct at the joins between systems and the return outlives the platform entirely.

Three rules keep automation portable: keep business logic outside the platform, treat the platform as one source among several rather than the centre of everything, and integrate through documented interfaces rather than platform internals. Business logic outside the platform is the one that matters most. If the rule deciding which orders need manual review lives in a platform-specific plugin or a theme template, it is discarded with the theme. If it lives in a workflow service or a small application you control, it survives and only its input connector changes. The same applies to email templates, approval thresholds and any mapping table between your products and a supplier's codes. Treating the platform as one source among several means normalising data at the edge. Orders arriving from a store, a marketplace or a spreadsheet should be converted into the same internal shape before any decision is made about them. When a new platform arrives, it becomes a new edge rather than a new workflow. Preferring documented APIs and webhooks over database access, template hacks or admin screen scraping is the third rule, and it is what makes the edge cheap to swap. Breaking each workflow down first makes all three easier, which is covered in break a workflow into tasks.

A Neto merchant weighing a Shopify move has an unusually clean version of this decision, because Neto's API makes the platform-dependence visible. Neto's public API is RPC-style: a single fixed endpoint per merchant domain, with the operation chosen by an HTTP header called `NETOAPI_ACTION` rather than by a resource path. Maropost's own developer documentation also states a rate limit of 500 requests per minute, monitored per account, returning HTTP 429 when breached, and applying regardless of plan tier. An integration written tightly against that shape does not transfer. Shopify's API uses different resource names, different pagination and different limits, so every call site, field mapping and retry strategy built around a header-selected action and a 500-a-minute ceiling is rewritten rather than adapted. If that integration was the thing you were about to commission, you would be commissioning it twice. Now the other side. An automation that watches the customer service inbox, classifies enquiries, drafts replies against order data and files them survives the move untouched. Its only platform-facing part is an order lookup. Swapping one lookup is a day of work, not a project. Same budget, same month, radically different residual value after the move. One thing to be clear about: Neto is not being switched off. Maropost published release notes dated 12 January 2026 and runs an open 14-day trial with no credit card required. The question here is whether you are leaving, not whether you are being pushed.

If a process is not consistent and not written down, neither automating it nor replatforming will fix it. An inconsistent process automated is an inconsistent process running faster. The same process moved to a new platform is the same mess in new clothes, and now nobody remembers how it used to work. The cheap test is to run it manually three times and write down the trigger, inputs, decisions and output on each run. If the three write-ups disagree with each other, you have found the actual first job, and it is not a software purchase. That method is set out in full in run it manually three times first. There is a volume test too. A workflow that runs twice a month and takes ten minutes is not worth building against, whatever platform it sits on. And there is a planning test that catches more merchants than either: if the replatform has no date and no signed scope, it is not a plan, it is an intention. Treat an undated intention as staying, automate on that basis, and revisit the sequencing question on the day someone actually commits to a date.

Should I automate my current platform if I might move within a year? Yes, for the workflows that sit between systems, and no for the ones inside the platform. Order handoffs to accounting, supplier chasing and customer enquiry handling all survive a move with one connector change. Product data work, merchandising rules and checkout logic do not, so those are the ones to hold. What if I have already paid for an integration built tightly against my current platform? Treat it as a sunk cost and value it on remaining life, not on what it cost. If the move is dated, the honest question is what it would cost to rebuild that integration on the destination platform, and whether that number changes the migration business case. It usually should be in the migration budget rather than hidden in it. Does automating now make the replatform harder? Only if the automation reaches deep into the platform. Automation that touches the platform through one documented API call or webhook is easier to migrate than the manual process it replaced, because the touch point is written down. Automation embedded in themes, plugins or platform-specific scripting adds work to the move. How do I classify a workflow that touches both sides? Split it. Most mixed workflows have a portable decision layer and a disposable read or write step against the platform. Build the decision layer properly outside the platform and keep the platform-facing step as thin as you can, ideally a single call. Then the move costs you that one call. How reliable are the replatforming overrun statistics? Less reliable than they look. Bloor Research is the one commonly cited set with a named research organisation behind it, at roughly 30 per cent average cost overrun and roughly 41 per cent average schedule slippage, but it covers enterprise data migration generally and the year is not confirmable. Most other circulating figures trace back to vendors with a migration to sell. What should I definitely not automate before a platform move? Bulk product data workflows, category and collection structure, on-site search and merchandising, discount and promotion logic, and tax and shipping configuration. All of them are rebuilt on the destination platform, several of them by hand, so automation built against them is written off at cutover.