Inheriting a client's existing site: what transfers to WebinOne and what gets rebuilt

The question an integrator asks before moving a client's site onto a new platform is not "can it be migrated". Almost anything can be migrated. The question is which parts arrive intact, which parts get rebuilt, who does the rebuilding, and what the client sees on the day it switches over.

Vague answers to that question are expensive. A platform that says "seamless migration, everything transfers" is describing a sales process, not a delivery plan, and the gap between the two shows up in week nine rather than week one. So this page answers it with the specific inventory rather than a reassurance, and where our own published process contradicts the comfortable version, it says so.

Migration here is a rebuild, and our own process page says so

Our published migration process describes the second step as follows: "We securely extract all your website data, including content, images, files, and user information, from your current CMS. Our team rebuilds your site on WebinOne, considering your current limits in the first version and delivering a new, enhanced solution."

Read that as an integrator rather than as a prospect. The data is extracted; the site is rebuilt. Those are two different operations with two different risk profiles, and the sentence does not blur them. Content comes across as content. The thing that renders it is built again on this platform.

That is the honest frame for every question below, and it is a better frame commercially than the alternative. Integrators do not fear a rebuild. Rebuilds are what they sell. What they cannot price is a platform that promises a lift-and-shift and then discovers, three sites into a portfolio, that the templates were never portable.

The named inventory: what is extracted from the source system

Our process page names four things: content, images, files, and user information. That is the list. It is worth more to you than the word "everything" would be, because a list can be checked against a specific client site before anyone signs anything, and "everything" cannot.

What that means in practice for a portfolio assessment: pages and their content, the media library, the file assets a site serves, and the records of the people who had accounts on it. If a client site's value is mostly in those four categories — and for a marketing site or a content-heavy corporate site, most of it is — then the bulk of what the client is paying you to preserve is in the extracted set.

If a client site's value is mostly in behaviour rather than content — a bespoke quoting engine, an integration doing real work against an ERP, a custom checkout flow with years of edge cases in it — then the bulk of it is not in that list, and it belongs in the rebuild column. Sort every site in a portfolio into those two piles before you quote. The sorting is the estimate.

What has to be rebuilt, stated plainly

The front end. Templates, layouts and the code that drives them are written against this platform's object model, so a source site's theme does not transfer as a runnable artefact. It transfers as a reference: a design to reproduce and a set of behaviours to reimplement.

This is the distinction worth being precise about, because it is where platform marketing is usually loosest. Owning your template files is not the same as those files being portable. You will own what your team writes here, and you can read it, edit it, version it and take a copy of it. It will also be written against this object model, which means that on some future platform it is documentation rather than code. That is true of every templating system, ours included, and a platform that implies otherwise is telling you something you can check.

Custom functionality is the other rebuild column. Where a source site did something specific, the question at assessment time is whether the platform's object model covers it directly, whether it is built as custom development alongside the platform, or whether the front end consumes the content through the headless API and the behaviour lives in your own application. Those are three real delivery paths, not one path and two fallbacks, and which one a given requirement takes is a scoping decision rather than a platform limit.

Who actually performs the migration

We do. Our published process for Business Catalyst partners states it directly: "Business Catalyst to WebinOne migration services are performed by the WebinOne Services team." The general migration page describes the same division — a consultation and planning stage, extraction and rebuild, the final migration and launch, then post-migration support — with our team handling the transfer itself.

For an integrator this is a resourcing fact, not a courtesy. The extraction and the platform-side rebuild are not line items you staff. What you staff is the part that was always going to be yours: the design decisions, the client relationship, whatever custom work sits on top, and the acceptance review before the site goes live.

It also means the migration has a counterparty with a name. If a portfolio move stalls, it stalls somewhere identifiable, which is a materially different situation from a self-service importer that half-succeeds and leaves you to reconcile the difference.

Where a migrated site sits before it is live

Not in production. Our Business Catalyst process describes it: "The migrated website will appear as a new trial site in your WebinOne Portal (you will be notified via email). During 30 days trial site period, with our help, you will be asked to perform minor setup actions." Going live is then a deliberate act — "Activate site in WebinOne Portal" — followed by handing the site to the client.

That trial-site stage is an acceptance gate, and it is the single most useful mechanism on this page for anyone moving more than one site. The migrated site exists, in your portal, reviewable, before it is anybody's production website. You can compare it against the original, find what the extraction did not carry, and fix it while the client's live site is still serving traffic from the old platform.

For a portfolio, that is also how you learn what a rebuild of these particular sites costs before committing to all of them. Move one. Review it in trial. Price the rest against what you actually found instead of against what the platform's process page promised — including this one.

What access you need from the incumbent platform

For Business Catalyst sites the requirement is published and narrow: "we only require Administration Access to a site to migrate the content." For other source platforms the access needed is established in the consultation stage rather than stated in advance, and that is the honest answer — a migration off an arbitrary CMS depends on what that CMS exposes.

Raise it early anyway, because it is rarely a technical obstacle and frequently a political one. The access has to come from whoever currently holds the client's platform account, and that is sometimes the incumbent agency being replaced. Establishing who can grant it, in week one, is worth more than any technical detail on this page.

What the client experiences on cutover day

Our process page describes the final stage as a swift transition "with minimal downtime, typically less than an hour, to keep your site available to your visitors." Treat that as what it is: our own figure for the cutover window, not an audited measurement and not a commitment attached to a specific site. Ask for it against your own case, and ask what it covers.

What that window does not cover is the part integrators actually get caught by, so plan it separately: DNS propagation outside anyone's control, URL structure and redirects from the old address space, and anything a client's analytics or ad platforms have pinned to specific paths. None of those are platform limitations. All of them are cutover work, and they are yours or ours by agreement rather than by default — so make the agreement explicit rather than assuming it.

What you hold afterwards

The commercial surface is published on our reseller program page, and the relevant items for an integrator inheriting client sites are these: "White-label all of the sites under your brand", "Granular white-labeling", "Branded subdomains", "Portal users management", "Customizable commission", and "direct billing is available". A free SSL certificate is issued for every live site.

In delivery terms: the client's sites sit under your brand in your portal, your team administers them, and the platform underneath is not a party to your client relationship unless you make it one. That is the arrangement most integrators want when they take over someone else's portfolio, and it is worth confirming against the page rather than taking from this one.

The exit question, answered before you ask it

Any integrator moving a client portfolio onto a platform should ask what happens if the platform disappears. Our terms of service carry a clause on it, and it is worth quoting exactly rather than summarising, because the scope of these clauses is where they usually disappoint: "In case of an unlikely event of the Service being closed or discontinued for any reason, we commit to open-source the WebinOne platform to the level that every Reseller would be able to host their trial and live sites, WebinOne Portal, and SSO service without our support."

Note what it is and is not. It is a commitment scoped to resellers — which is the capacity an integrator holds here — covering trial sites, live sites, the portal and SSO. It is not a source-code escrow agreement, and there is no third-party escrow arrangement behind it. If your client's procurement requires escrow specifically, raise it during the technical assessment so it is addressed before signature rather than discovered after it.

What to ask for before you move a portfolio

Four things, and none of them require a commitment from you.

First, run one site through the process end to end and review it in the trial stage. Everything else on this page is a description; that is a measurement, on your client's actual content.

Second, sort the portfolio into the extracted pile and the rebuilt pile, site by site, using the named inventory above. The second pile is the entire commercial risk in the project.

Third, get the access question answered for every source platform in the portfolio, not just the one you know well.

Fourth, ask the questions that are not about migration at all — where the client's data sits, who operates what, and what the platform does not do well. Those are answered separately in our AWS architecture briefing for integrators, in where WebinOne is the wrong choice, and in the requirements checklist in what to require from a legacy DXP migration. The evaluation framework that sits above all of them is how to evaluate a white-label DXP.

WebinOne is an AWS-native digital experience platform built by Upgrade Parade Corp, formerly Treepl CMS, and the migration path off a discontinued platform is where it started — the product exists because Business Catalyst was shut down and its partners needed somewhere to put several thousand client sites. That history is why the process above is a service with people attached rather than an importer button, and it is also why we are careful about the word "seamless" in a room full of integrators.

Migration scoping and portfolio pricing run through the technical assessment: contact us to start one. The platform-side detail lives on migration to WebinOne, the partner terms on the reseller program, and the security posture, including the shared responsibility split and where customer data is stored, on the security overview.