What is WebinOne? A briefing for systems integrators

WebinOne is an AWS-native digital experience platform built by Upgrade Parade Corp, formerly Treepl CMS. It is delivered white-label: agencies and systems integrators build, host and support their clients' sites on it under their own brand, and the platform stays invisible to the end client.

That sentence is the whole of it, but it is not what most people need before a first call. What follows is the briefing an integrator's solutions architect usually asks for — who builds the platform, where it physically runs, what a partner's delivery model on it looks like, what it replaces, and where its boundaries are.

What is WebinOne, in one paragraph?

A hosted digital experience platform — content management, ecommerce, CRM and a headless API in one system — that partners resell under their own brand. It runs on Amazon Web Services infrastructure operated by the platform team, so a partner delivering on it takes on the build and the client relationship without taking on the hosting stack.

The category word matters for anyone comparing shortlists. WebinOne is a DXP rather than a website builder: the same system holds the content model, the customer records, the transactions and the API surface, instead of assembling those from separate products. That is a deliberate boundary and it has a cost as well as a benefit, which the sections below get to.

Who builds it, and what was it called before?

Upgrade Parade Corp builds and operates WebinOne. The platform was called Treepl CMS until it was rebranded, and it is the same product line and the same engineering team — if you find documentation, partner pages or reviews under the Treepl name, they refer to this platform.

That history is worth knowing rather than glossing over, because an evaluation done today will surface Treepl-era material written by third parties, some of it years old. The current platform, the current partner programme and the current hosting footprint are all documented under the WebinOne name.

Where does WebinOne run?

On AWS, across six AWS regions, with data residency options for compliance requirements. Which location a specific client's site runs in, and what residency options apply to it, is confirmed in the technical assessment. If a client's requirement falls outside the current footprint, an additional AWS region can be stood up on request — that is a matter of hours of provisioning work rather than a procurement cycle, because the footprint is built on AWS rather than on our own metal.

Beyond shared infrastructure there is a dedicated server option for workloads that need isolation or their own performance envelope. Availability measured across the last twelve months was 99.99% — that is a historical measurement of what the platform did, quoted here as a fact rather than as a service commitment; the commercial terms are a separate conversation with their own document.

Whose account it runs in is the question an AWS-native integrator asks first, so it is worth answering plainly rather than leaving to inference: today it runs in ours. Production sites sit in the platform's own AWS account, operated by the platform team, and that is the arrangement every partner is delivering on right now. A different arrangement is a commercial conversation rather than a setting — a custom licensing and setup quote, agreed deal by deal — so if your practice needs the platform running inside an account you hold, raise it early and get it priced rather than assuming it either is or is not possible. What remains genuinely open in the default is narrower: exactly where the responsibility boundary falls between the platform team and your own practice. That one is answerable against your actual estate in the technical assessment instead of in general terms.

Who delivers on WebinOne — agencies, integrators, or both?

Both, and the distinction is real rather than cosmetic. Web agencies were the platform's first partner population and remain a large part of it; systems integrators and consultancies with their own AWS practice are a newer and structurally different one, and the platform is delivered to both under the same white-label model.

The difference shows up in what each partner wants from the platform. An agency typically wants build speed and a hosting stack it does not have to run. An integrator usually arrives with an AWS practice already, a client estate already under contract, and a different question: whether the platform fits inside a delivery model and a security posture it already has. Those are not the same evaluation, and a platform page written only for the first one answers the wrong question for the second.

What does WebinOne replace?

Ageing CMS and DXP estates, most often when the incumbent platform is being retired, has become expensive to maintain, or no longer has anyone left who knows it. The platform's own origin is exactly that: it was built as the destination for sites leaving Adobe Business Catalyst when that product was discontinued, and the Business Catalyst migration path is still documented for partners who inherit those estates.

That origin explains a lot about how the platform is shaped. It was designed from the start around taking over somebody else's sites in volume rather than around greenfield builds — more than 3,000 sites have been migrated onto it. The practical detail of what that involves is in the migration documentation, and the platform-side requirements an integrator should put to any vendor before starting one are set out in our article on what an integrator needs from a platform before migrating a client off a legacy DXP.

What is in the platform?

Content management, ecommerce, CRM and customer records, forms and member accounts, and a headless API over the same data. They are components of one system rather than integrated products, which means the customer record a form writes to is the same record the ecommerce side reads.

The headless API matters most to the integrator reader, because it is the boundary between what the platform does and what a partner's own engineering team does. Front-end work can be done in the platform's own template layer, or the platform can serve as the content and commerce back end for a front end a partner builds and hosts themselves. Custom development around the platform is a normal delivery pattern rather than an exception — development and ongoing support are both documented as partner-facing services.

One thing to understand about the boundary before you test it: it moves, but it moves as project work. The API surface and the platform's functionality are both extended when a delivery needs something they do not yet cover, and that happens regularly rather than exceptionally — but it is scoped, quoted work with a delivery date, not a feature flag somebody turns on. So the useful question in an evaluation is not whether the platform can do a thing; it is whether the version that exists today covers the build in front of you, and what the gap costs if it does not.

How does an integrator work with WebinOne commercially?

Through the partner programme, which is a resale relationship: the partner holds the client contract, sets their own pricing, and the platform is not a party to the end-client relationship. There are more than 100 licensed and reseller partners on this model, working in 16 countries.

For a firm whose product is delivery capacity, the useful framing is that the platform occupies a narrow commercial layer. It does not sell to your client, it does not appear to your client, and it does not compete for the work around it — the build, the integration, the ongoing account. That is the whole basis on which a partner can put their own brand on it.

Where does delivery capacity come from when a portfolio lands at once?

TeamOne is surge capacity working under a partner's brand, on work the partner has already won, under the partner's own project management. It exists for the shape of problem where a portfolio migration arrives as a spike rather than as a run rate, and hiring against the peak is the wrong answer.

AgentOne is the platform's automation layer for delivery work, currently in Partner Beta. Its purpose is to automate and accelerate steps in the build process; it is worth knowing exists during an evaluation, and it is not a reason to choose the platform.

What does WebinOne not try to be?

It is a digital experience platform, not a general-purpose application platform. Custom back-end services, heavy data processing and bespoke business logic sit alongside it — built by the partner, talking to it over the headless API — rather than inside it, and an evaluation that assumes otherwise will find the boundary late and expensively.

Naming the boundary early is more useful than claiming there isn't one. A fuller account of where this platform is the wrong choice does not belong hedged inside a positive page, so ask for it directly during the assessment — the cases where we are the wrong fit, named rather than described in adjectives. An evaluator gets more out of that answer than out of anything on this page.

Who already runs on it?

Agencies, enterprises and government organisations across 16 countries, on more than 100 licensed and reseller partnerships. Named, verifiable deployments — the kind an architect can open and inspect rather than take on trust — are collected on the enterprise page, including Mammoth Nation, Green Industries South Australia and Dellner Bubenzer.

Government and public-sector clients are part of that population, which is usually the point at which a security reviewer wants specifics rather than adjectives. Those specifics — what the platform holds and does not hold in the way of formal certification — are stated plainly in the migration requirements article linked above, and are not softened here.

What is the first step for an integrator?

A technical assessment against one real client estate rather than a demo. The questions worth bringing are the ones that decide the answer: where the sites will physically run, what the content model has to absorb, where the boundary sits between the platform and your own engineering, and what the commercial layer looks like against your existing contracts.

That conversation starts here. If you would rather read first, the platform-side evaluation checklist is the legacy DXP migration article, and it is written for the same reader as this page.