Migrating a client off a legacy DXP: what an integrator needs from the platform

An integrator evaluating a platform for a client migration is not shopping for features. You are deciding whether you can put your firm's name on a cutover date, and whether the platform will still be a defensible recommendation two years after the invoice clears. Those are different questions from the ones a vendor feature page answers.

WebinOne is an AWS-native digital experience platform (DXP) operated by Upgrade Parade Corp, formerly Treepl CMS. It is sold through partners, not around them. Below are the questions solution architects and delivery leads actually put to us — including the places where the honest answer is a qualification rather than a claim.

What actually breaks in a legacy DXP migration?

Not the design. Four things break, in this order of pain: the content model, the integrations, URL and redirect continuity, and the editors' working habits.

The content model is first because legacy platforms encode structure inside proprietary templates. A page that looks like one object is often three — a layout, a content record, and a set of custom fields that only exist because someone needed them in 2017. Mapping that to a new model is the work; rebuilding the front end is comparatively cheap.

URL continuity is the item that gets escalated to the client's marketing leadership, because a broken redirect map shows up as lost organic traffic within a week of cutover. Treat it as a deliverable with its own sign-off, not a post-launch cleanup task. Page and redirect count, not visual design, is what sets a migration timeline — the figure we publish for our own enterprise migrations is 10,000+ pages transferred.

Editor retraining is the item most often left out of the estimate and the one that generates the support tickets in month two.

Does a platform that ships faster cost us billable hours?

It changes what the hours are spent on, and it moves margin inside a fixed-price bid. If your practice bills a long service tail on a platform your own team hand-maintains, that is a genuine economic difference and you should test it against your own numbers rather than take our framing for it.

The figure that matters is not hours per project. It is projects per architect, and margin retained inside a fixed scope. On a migration engagement the billable work is discovery, content modelling, integration design, redirect strategy, data cleanup, editor enablement and managed services after cutover. None of that moves. What compresses is the undifferentiated part: environment setup, templating, and the upgrade-and-patch tail your senior people absorb without billing it cleanly. If your growth constraint is senior capacity rather than pipeline, that is the number to model.

Where does the platform run, and who is accountable for uptime?

On AWS, across six data centers — US East, US West, Canada, London, Frankfurt and Sydney — with 99.99% uptime over the last 12 months. Accountability sits with us, not with your client's ops team and not with a reseller in the middle. If your firm is an AWS partner, the migration is a workload move inside the ecosystem you already operate in rather than a move to someone else's cloud.

Data residency is selectable, which is what makes public-sector work possible: Green Industries South Australia, a South Australian government body, runs on the platform, as do US government clients. Be clear about what that is and is not. It is production government work on AWS. It is not a FedRAMP authorization, and we are not CMMC-certified. If your client's procurement requires either, we do not clear that bar today, and you should hear it here rather than in week three of a pursuit.

For workloads with hard performance floors there are dedicated server configurations rather than a shared tier you discover during a load test. Burst capacity is scheduled and pre-purchased rather than autoscaled — one client buys extra capacity around national television spots instead of paying for peak headroom year-round, provisioned within one business day. That is deliberately cheaper for planned load. If the workload spikes without warning and you carry the SLA, size for it up front.

Who owns the client relationship after cutover?

You do. We do not sell to your client, we do not price around you, and we do not put our brand in front of theirs — the partner portal is white-label by default, including billing and support routing.

The commercial layer is deliberately narrow: we license the platform, you bill implementation, customization and managed services on top. Every layer where an integrator earns is a layer we do not sell into, which is why a firm can build a repeatable practice on this rather than treat each engagement as a one-off resale.

What happens to your client if WebinOne goes away?

They can leave on their own schedule rather than on ours, and that is the only protection worth anything here. Name the gap first, because a vendor that gets vague at this question has earned the lock-in objection: there is no contractual continuity guarantee today — no committed wind-down notice period you can put in a client's risk register.

What mitigates it is design rather than assurance, and three things carry it. The export is a scripted job your team runs on a schedule you set, so a current copy of the content sits with the client continuously instead of being requested during a crisis. A decoupled front end your team builds against the headless API survives a back-end change, which bounds the exit to replacing a back end — the only durable guarantee any SaaS platform can actually give you. And escrow and a licensed, partner-hosted deployment are contract-stage conversations rather than shipped guarantees, so raise both in the assessment if your client's risk profile requires them.

Content, structured data and media are reachable through an authenticated API. Do not accept the phrase “full export” from any vendor, including us — name the inventory in the assessment and get it in writing: custom module schemas as well as their records, member accounts, form submissions, order history where the site transacts, media at original resolution, and the redirect map. Then plan the extraction itself, because pulling a 10,000-page estate through an authenticated API is a scheduled job rather than an afternoon.

Templates and front-end markup are yours as files, but be precise about what that is worth: they are written against this platform's object model, so they port as reference rather than as runnable code. If portability is a hard requirement for your client, that is the argument for the decoupled path above.

What does not exist: an open codebase, and today, no source-code escrow arrangement. We do not offer closed source as a security feature — it isn't one. The honest reason the code is closed is that we build and maintain every extension in-house, which is the actual contrast with an assembled plugin estate. If a client's procurement requires escrow, raise it during the assessment so we can address it before signature. A licensed, partner-hosted deployment option is under evaluation. We are not putting a date on it, and you should not design a client's architecture around it.

Will the client have to replatform again in three years?

No, and that is a design constraint rather than a marketing promise: partners on WebinOne do not need to migrate off it as sites grow. Scale ceilings become a configuration change on dedicated infrastructure, and the headless API means a client who later wants a decoupled front end keeps the same back end instead of buying a new one.

The third driver is behind most of the moves we see, and it is not traffic — it is accumulated third-party dependency. A WordPress estate assembled from plugins ages badly because each plugin carries its own release cadence, security posture and abandonment risk, and the integrator inherits all of it. Sitecore, Sitefinity, Magnolia and dotCMS estates fail differently, usually on upgrade cost and specialist scarcity, but the outcome for your delivery team is the same. Native, in-house extensions trade ecosystem breadth for a maintenance surface you can forecast.

Where does complex back-end and integration work live?

In your own services, integrated over the API — not inside the platform's templating layer. Any vendor claiming all of it belongs inside their DXP is describing a ceiling, not an architecture.

In-platform work is templating, module and content-model configuration. Custom services — a pricing engine, an ERP sync, an identity broker, a data pipeline — belong in your stack, deployed alongside the site in the same cloud and talking to the platform over the API. That is the boundary you would draw on any DXP; the difference is that the platform side is already on AWS, so the integration crosses neither clouds nor vendors.

Check two things against your client's requirements rather than assume them: enterprise SSO and identity-provider integration, and any protocol-level requirement their security team has already committed to. Put both in the assessment and get a written answer.

How do you absorb a 400-site migration without hiring against a peak?

Surge capacity under your brand, on work you have already won. TeamOne is our delivery bench — development, design, QA and project management — available to partners as white-label overflow that you scope, direct and mark up.

It exists because migration volume arrives unevenly. A 400-site consolidation does not map onto a staffing plan built for quarterly project flow, and the alternatives are declining the scope or staffing to a peak that ends. Bulk migration onto this platform is a motion our team runs continuously, so that throughput is available on the mechanical portion of a large cutover — under your project management, alongside your architects rather than instead of them.

AgentOne is the other half of that capacity question, and it is in Partner Beta. It automates and accelerates delivery work on sites already running on the platform, and the part partners have measured on their own material is design-to-code conversion. We are not publishing a conversion rate here, because the only figures we have were measured on one partner's private design files rather than on a sample we can describe. Ask for the measurement on your own designs during the evaluation — that is the only number that should inform your pricing. Because it is Partner Beta, evaluate it against a real workload before you price it into a fixed-scope commitment, and put your security team's questions to us during that evaluation rather than after it.

Who already runs on this, and how can an architect verify it?

Over 100 licensed partners across 16 countries, plus US and Australian government clients — and the enterprise work is published with client names, so you can check it rather than take it on faith.

The migration record is the part most relevant here. The platform originated as the migration path off Adobe Business Catalyst when Adobe retired it, which made bulk-migrating live production sites the founding requirement rather than a feature added later. Over 3,000 sites have been migrated onto the platform from various CMS platforms since. Named enterprise examples, including Dellner Bubenzer, Mammoth Nation, Green Industries South Australia and Lochow Ranch Surveys, are on the enterprise page with the scope of each build.

What is the right first step?

A migration assessment against a real inventory, not a demo. What we need from you is the page count, the content types, the integration list and the current redirect map. What you get back is a scope, a timeline, and the specific items we think will be difficult.

That last part is the point of the exercise. If a platform vendor reviews your client's legacy estate and comes back with no difficult items, they have not read it. Start the conversation here, or send the inventory and we will work from it.