When is Patchworks deprecating Tapestry?

Patchworks has not published a specific sunset date for Tapestry at the time of writing. The deprecation is in progress and the direction is unambiguous: Core is the platform Patchworks is investing in, and new feature development on Tapestry has effectively stopped. Merchants who plan now have more options than merchants who wait until a deadline is announced and the partner-agency calendar fills up.

Can we wait, or do we need to start now?

Waiting is rational if the Tapestry estate is small, stable and not blocking new commerce work. Starting now is rational if the estate is large, has a NetSuite component, or has accumulated workarounds that the migration to Core would naturally simplify. The audit is the cheapest way to make the decision with real data rather than a guess; ten working days, a written deliverable, and a recommendation either way.

How long does a Tapestry to Core migration actually take?

Highly estate-dependent. A small merchant with two or three flows and no NetSuite component can be moved in a few weeks under a cutover approach. A mid-market estate with NetSuite, multiple sales channels and accumulated customisations runs in phases over two to four months. We have a Phase 1 currently live for WYSE London that we describe in the case study; even Phase 1 alone is meaningful work. The honest number comes out of the audit.

Do we lose any functionality moving from Tapestry to Core?

Not in our experience to date. Every Tapestry pattern we've migrated has a Core equivalent that handles it as well or better. The shape of the work changes (Core's flow editor is more flexible, monitoring is different, the NetSuite integration moves from SuiteScript to REST), but the operational outcomes are preserved. Where Core changes things, it usually consolidates rather than fragments: Web and POS orders that ran in separate Tapestry flows can sit in a single Core flow.

Is the migration risky to live operations?

Less than it sounds, because there is almost always a working Tapestry integration to model the Core build against. Data risk is minimal under a phased approach: the existing Tapestry flow keeps running while the Core flow is built and tested against the same source, and cutover happens endpoint by endpoint with parallel running where the operational shape allows it. For smaller estates a one-go cutover is workable; for anything material we phase.

Do we need a Patchworks Partner Agency to migrate, or can our incumbent do it?

Either route is possible. The migration is engineering work, not a Patchworks-exclusive operation. We deliver migrations on Patchworks daily and audit migrations other partners have built; the agency choice depends on the same dimensions as picking a Partner Agency for any other engagement (see our buyer guide). If you're already on a Partner Agency you trust, the audit is the cleanest way to get a second opinion on the migration scope before committing.

What's a realistic cost range for the full migration project?

We don't publish project price ranges because they're misleading: a single-channel SMB migration and a multi-channel mid-market NetSuite migration are different orders of magnitude. The audit gives a defensible estimate against the merchant's actual estate within ten working days; that estimate is what to plan against, not a generic figure off a website.

Does the £750 audit fee come off the migration project?

Yes. The full audit fee is credited against the subsequent migration engagement if you commission us within thirty days of audit sign-off. The credit is automatic and does not depend on engagement size. Functionally the audit is a paid scoping exercise where the cost rolls into the project if both sides decide to proceed.

Migration handbook

Patchworks Tapestry to Patchworks Core: the migration handbook.

Patchworks is in the process of deprecating Tapestry in favour of Core. No public sunset date yet, but the direction is unambiguous and the work to migrate is non-trivial. This handbook covers what's materially different between the two platforms, how a typical migration plays out, where the work actually lives, what the £750 audit delivers, and the honest read on timeline pressure. Written by an agency that ships Tapestry-to-Core migrations as Patchworks Partner work.

What's materially changing

Monolithic platform to a flexible one.

Tapestry was the right answer for the integration patterns of its time. The architecture was monolithic by design: connectors and flows ran inside the same deployment, with change cycles that involved redeploying the platform itself. That worked for the integration shapes the market asked for in the late 2010s, but it made several patterns harder than they needed to be. Real-time changes, on-the-fly customisation, consolidated multi-channel flows and the ability to swap connector behaviour without redeploying were all friction points rather than primitives.

Core is a rebuild around flexibility. Flows are dynamic. Connector behaviour can be updated without redeploying the platform. Configuration changes that used to require a release on Tapestry are configuration changes on Core. The flow editor is more permissive about consolidating logic that Tapestry forced into separate flows: where Web orders and POS orders had to run as distinct Tapestry flows because of how the underlying transport worked, the same logic can sit in a single Core flow with branching at the right point.

Operationally this is the bigger change than the surface UI suggests. Tapestry asked merchants to plan changes against a release cadence; Core asks them to plan changes against an operational moment. The integration estate becomes faster to evolve, which is the actual point of the move.

Why plan now, not later

No deadline yet, but the direction is set.

Patchworks has not announced a public Tapestry sunset date at the time of writing. We expect one to land, and the investment direction of the platform is unambiguous: Core is what's being built, supported and extended. Merchants who plan the migration before a deadline forces it tend to land softer than merchants who wait until the calendar fills up.

Plan early if

The estate has a NetSuite component (the largest single category of migration work).
Tapestry flows have accumulated workarounds that the move to Core would naturally simplify.
The estate runs critical commerce volume; you want phased, not cutover, and phasing needs lead time.
Operations is asking for change-cycles Tapestry's architecture makes painful.

Waiting is rational if

The estate is small, stable, and not blocking new commerce work.
You have no NetSuite component, or the NetSuite footprint is light.
Operations isn't asking for change-cycles Tapestry's monolith struggles with.
You already have a Patchworks Partner Agency engaged who can absorb the migration into existing capacity.

What the shift means in practice

Consolidation, not fragmentation.

The Tapestry-to-Core move tends to make a merchant's integration estate smaller, not bigger. Patterns that required multiple parallel Tapestry flows can collapse into a single Core flow with branching: Web orders and POS orders sharing one canonical sales-order pipeline; B2B and DTC sharing the customer and pricing logic; marketplace orders joining the same fulfilment writeback instead of running through their own parallel flow. The audit usually surfaces consolidation opportunities that were impractical on Tapestry's architecture.

On the operational side, the change-cycle gets faster. Updating a mapping, swapping a destination, adjusting an enrichment rule on a connector are configuration changes on Core where they used to be release-cycle changes on Tapestry. That matters less for stable estates and a lot for estates where operations and finance are still iterating on the integration shape.

Migration shape

Phased for material estates, cutover for small.

The shape of the migration depends almost entirely on estate size. Two patterns cover most real migrations.

Pattern A

Phased, with parallel running

The default for mid-market and enterprise estates. Tapestry flows continue to run live; Core flows are built and tested against the same source data in parallel. Cutover happens endpoint by endpoint, with the Tapestry flow disabled only once the Core flow is shown to behave identically across a verification window. Phase 1 typically covers the heaviest-traffic flow (usually orders); subsequent phases cover inventory, products, customers, fulfilment writebacks, refunds and the long tail.

Pattern B

Cutover, one go

The default for smaller estates with two or three flows and a known data shape. Core flows are built and tested end to end, a quiet operational window is chosen, and the cutover happens in a single planned change. Faster and cheaper than phasing, with the trade-off that the window of risk concentrates into a single weekend rather than spreading across phases.

Data risk is lower than it sounds on either pattern, because there is almost always a working Tapestry integration to model the Core build against. The Tapestry flow tells us what the data shape should look like; the Core build matches it. Edge cases that were live on Tapestry continue to be live on Core; edge cases that were broken on Tapestry can be fixed during the migration rather than carried forward.

Where the work actually lives

NetSuite, every time.

For any merchant with NetSuite in the estate, the single largest category of migration work is the NetSuite side. Tapestry handled NetSuite integration through patterns that leaned on SuiteScript and bespoke record-handling logic; Core handles it through NetSuite's REST API, which is materially more mature and better-specified than the APIs available when Tapestry's NetSuite integration was originally designed.

That shift is good news for the long run: REST is a cleaner interface, better-documented, easier to extend and easier to debug. It is also the part of the migration that needs the most engineering attention. Record-handling patterns differ between the two approaches. Custom transaction types, OneWorld subsidiary routing, custom record references, locked- period handling and the various NetSuite scenarios where Tapestry leaned on script-side logic all need to be re-implemented at the REST layer. The migration audit spends most of its time mapping these explicitly so the re-implementation can be scoped against reality rather than guesswork.

For merchants without NetSuite the work is smaller and more linear: connector behaviour, flow shape and monitoring move to the Core equivalents, the operational tests confirm parity, the cutover happens. NetSuite is where the genuinely hard engineering sits.

The £750 audit

Productised scoping, credited against the project.

The Tapestry to Core variant of our Integration Audit is a fixed-fee, fixed-scope piece of work scoped specifically for migrations. Same ten working days, same written deliverable, same credit policy as the standard audit. The fee comes off the migration project in full if you commission it within thirty days.

In scope

Audit of the existing Tapestry service estate: every flow, every connector, every mapping in current production.
Mapping of what migrates as-is versus what changes shape on Core. The NetSuite footprint gets explicit attention.
Consolidation opportunities: flows that ran in parallel on Tapestry because of architectural constraints, and can be unified on Core. Web + POS sharing one sales pipeline is the canonical example.
Recommended migration shape (phased vs cutover) with reasoning against your estate.
Cost and effort estimate for the migration project, in pounds and weeks.
60-minute walkthrough call with the founder once the report lands.

Not in scope

The migration build itself. The audit produces a defensible scope; the build is the subsequent engagement.
Workshop time with operations or finance teams beyond what the report requires. We focus on the technical reality first; stakeholder workshops come at project start.
Custom training material for in-house engineering. Available as a separate engagement.
Long-form documentation of the existing Tapestry estate beyond what the audit needs. The audit report covers the migration scope; broader documentation is a separate ask.

See the Integration Audit service page for the full audit shape, the pricing page for both audit variants and retainer tiers, and the buyer guide for the dimensions worth comparing if you're also evaluating other Partner Agencies.

Field note

From a live migration.

We have a Phase 1 migration currently live for a UK mid-market merchant. The full estate is multi-system, multi-currency and runs material commerce volume. Phase 1 alone has been intensive work: the NetSuite side consumed more engineering time than the rest of Phase 1 combined, even with a working Tapestry integration as a reference for the data shape. Subsequent phases continue into the rest of the estate.

The takeaway for buyers reading this: a Tapestry-to-Core migration that involves NetSuite is genuinely substantial work even when the team running it has shipped many Patchworks integrations. The £750 audit exists to make that real to you in writing before you commit, not to soften the news after the project is signed. The WYSE London case study covers the engagement in detail and is the closest public reference we have to what a phased Tapestry-to- Core migration looks like end to end.

Questions

Common questions.

01 When is Patchworks deprecating Tapestry?

Patchworks has not published a specific sunset date for Tapestry at the time of writing. The deprecation is in progress and the direction is unambiguous: Core is the platform Patchworks is investing in, and new feature development on Tapestry has effectively stopped. Merchants who plan now have more options than merchants who wait until a deadline is announced and the partner-agency calendar fills up.
02 Can we wait, or do we need to start now?

Waiting is rational if the Tapestry estate is small, stable and not blocking new commerce work. Starting now is rational if the estate is large, has a NetSuite component, or has accumulated workarounds that the migration to Core would naturally simplify. The audit is the cheapest way to make the decision with real data rather than a guess; ten working days, a written deliverable, and a recommendation either way.
03 How long does a Tapestry to Core migration actually take?

Highly estate-dependent. A small merchant with two or three flows and no NetSuite component can be moved in a few weeks under a cutover approach. A mid-market estate with NetSuite, multiple sales channels and accumulated customisations runs in phases over two to four months. We have a Phase 1 currently live for WYSE London that we describe in the case study; even Phase 1 alone is meaningful work. The honest number comes out of the audit.
04 Do we lose any functionality moving from Tapestry to Core?

Not in our experience to date. Every Tapestry pattern we've migrated has a Core equivalent that handles it as well or better. The shape of the work changes (Core's flow editor is more flexible, monitoring is different, the NetSuite integration moves from SuiteScript to REST), but the operational outcomes are preserved. Where Core changes things, it usually consolidates rather than fragments: Web and POS orders that ran in separate Tapestry flows can sit in a single Core flow.
05 Is the migration risky to live operations?

Less than it sounds, because there is almost always a working Tapestry integration to model the Core build against. Data risk is minimal under a phased approach: the existing Tapestry flow keeps running while the Core flow is built and tested against the same source, and cutover happens endpoint by endpoint with parallel running where the operational shape allows it. For smaller estates a one-go cutover is workable; for anything material we phase.
06 Do we need a Patchworks Partner Agency to migrate, or can our incumbent do it?

Either route is possible. The migration is engineering work, not a Patchworks-exclusive operation. We deliver migrations on Patchworks daily and audit migrations other partners have built; the agency choice depends on the same dimensions as picking a Partner Agency for any other engagement (see our buyer guide). If you're already on a Partner Agency you trust, the audit is the cleanest way to get a second opinion on the migration scope before committing.
07 What's a realistic cost range for the full migration project?

We don't publish project price ranges because they're misleading: a single-channel SMB migration and a multi-channel mid-market NetSuite migration are different orders of magnitude. The audit gives a defensible estimate against the merchant's actual estate within ten working days; that estimate is what to plan against, not a generic figure off a website.
08 Does the £750 audit fee come off the migration project?

Yes. The full audit fee is credited against the subsequent migration engagement if you commission us within thirty days of audit sign-off. The credit is automatic and does not depend on engagement size. Functionally the audit is a paid scoping exercise where the cost rolls into the project if both sides decide to proceed.

Get in touch

Tell us what you’re trying to connect.

And what’s in the way. We will tell you whether we are the right people to do it. Drop us a line below, or open the chat in the corner of the screen.

Direct: contact@ecirql.com