Migrating a Portfolio of Websites: How Enterprise Re-Platforming Is Scoped, Priced and Delivered
Most platform-migration content is written for one website. A portfolio is a different problem. When an organisation owns forty, four hundred or two thousand sites across three or four legacy platforms, the hard parts are not the CMS features — they are scoping work nobody has inventoried, pricing an engagement rather than a subscription, and moving live traffic without a month of blackouts.
This is how a portfolio migration to WebinOne — the AWS-native DXP by Upgrade Parade, formerly Treepl CMS — is actually scoped, priced and delivered. Where a figure is ours, it is labelled as ours.
What makes a portfolio migration different from moving one site
Three things change at volume.
The first is inventory. Nobody in the organisation has a current list. Sites were built by agencies that no longer exist, on platforms that were current a decade ago, with integrations that were never documented. The migration cannot be quoted until that list exists, which means the first phase of the work is discovery, not development.
The second is variance. In a portfolio of a hundred sites, ten are genuinely complex and ninety are brochures. Pricing all hundred as if they were the complex ten makes the project unaffordable; pricing them as if they were the ninety guarantees the project overruns. Portfolios are priced in tiers, not per unit.
The third is that a portfolio has a decommissioning problem as well as a build problem. Every site that moves leaves behind DNS, certificates, redirects, form handlers, analytics properties and someone's login. That tail is where re-platforming projects quietly lose their savings.
What actually transfers, and what gets rebuilt
Our own migration page names the extraction inventory rather than promising everything: content, images, files, and user information. That is deliberate, and it is the honest boundary.
What does not transfer is code. The same page says, in our words, "Our team rebuilds your site on WebinOne." Templates, layouts and any custom functionality written against another platform's object model are rebuilt against ours. They port as reference material, not as runnable code.
That framing is better for the buyer than the alternative, even though it sounds like more work. A rebuild can be scoped, quoted and accepted. A lift-and-shift that promises to preserve everything discovers the exceptions after the invoice, and the exceptions are always the integrations.
Structure survives the rebuild. On our enterprise page we publish 10k+ pages transferred — our own figure, across our own projects — described as content and metadata transfer with stable redirects, internal linking and structure. For a portfolio migration that is the number that matters more than the site count: URLs and redirects are what protect the search equity the organisation has already paid for.
Who does the work
The migration is delivered by our services team, not handed to the customer as a toolkit. That is the model on our migration page, and it is what our bulk-migration experience is built on: we publish 3k+ migrated websites and over five years of dedicated migration experience. Both are our own figures, self-published, and worth asking us to evidence on a call — we will.
For enterprise customers the same team that runs migrations is available afterwards for development work through TeamOne and for ongoing platform support. Practically, this matters more than it sounds: the failure mode in portfolio re-platforming is a migration vendor who disappears at cutover and leaves the receiving team with ninety sites they have never operated.
How a portfolio migration is scoped
Scoping is a paid, structured phase and it produces four things:
- A verified site inventory, tiered by complexity, with the sites that should be retired rather than migrated marked as such.
- An integration list — payment, CRM, single sign-on, data feeds — with a decision on each: rebuild, replace, or drop.
- A URL and redirect map, per site, agreed before any content moves.
- A cutover sequence, in waves, with the lowest-risk sites first.
The output of that phase is what the commercial agreement is written against. We do not quote a portfolio from a site count, and no vendor who does has read your portfolio.
How it is priced: one engagement, not a subscription per site
This is the question enterprise buyers ask first and most platform pages answer worst.
A portfolio migration is priced as a project fee for the migration work plus a recurring fee to host and support the resulting sites. One agreement covers the portfolio. Four hundred sites do not mean four hundred sign-ups, four hundred invoices, or four hundred plan selections made by whoever happened to be logged in.
That structure exists because it is the only one that survives procurement. Our own enterprise page names the pain plainly: every new tool adds cost and another contract to manage. A consolidation project that replaces four legacy platforms with four hundred individual subscriptions has not consolidated anything.
We publish plan pricing for individual sites, and portfolio work is not that. Portfolio pricing is quoted against the scoping output, deal by deal. If a page tells you what a portfolio migration costs before anyone has counted the sites, that number is marketing.
What the recurring cost covers after cutover
After cutover the portfolio runs on our infrastructure on AWS. Most sites in a portfolio run on the platform as it comes. Where a specific workload needs its own infrastructure, dedicated server deployments are available: our own dedicated-server page states those configurations in cores and RAM, which is the level of detail an infrastructure reviewer can actually price.
One thing to know before you plan around it: a dedicated deployment is scoped to a single site, and our page says anything beyond one site is treated as a custom setup. So a portfolio does not arrive as one dedicated server per site — if isolation for a specific high-traffic site matters, name that site during scoping so it is priced correctly rather than discovered later.
Where the sites run, and what that means for residency
WebinOne runs on AWS across six AWS regions, with data residency options for compliance requirements. The mechanism is published on our security overview rather than implied: customer data is stored exclusively in the designated AWS region, and content stored in WebinOne — assets, for example — is not replicated to other regions.
For a regulated portfolio that is the sentence that matters, because "we host in your region" and "we do not copy your data out of your region" are two different commitments and the second one is the one your compliance team is actually asking about. If a portfolio needs a region we do not currently run in, an additional AWS region can be stood up on request; which region a specific portfolio lands in is confirmed during the technical assessment.
Security: know where the line is drawn
Our security overview publishes the shared-responsibility split in AWS's own terms rather than gesturing at it. AWS operates, manages and controls the components from the hypervisor virtualization layer down to the physical security of the facilities in which WebinOne operates. WebinOne assumes responsibility for the guest operating system, including updates and security patches, the application software, and the configuration of the AWS-provided security group firewall.
Read that as a boundary map for your own review, because it tells you which questions we can answer and which ones belong to AWS's compliance documentation. Two things worth naming for a portfolio owner: we publish that platform data is stored in Amazon EBS and backed up via snapshot lifecycle policies every 12 hours, and platform status and incident history are published on our system status page rather than sent on request.
What we are not: we hold no FedRAMP authorisation and no CMMC certification. If your portfolio has a requirement in that class, that is a disqualifier and it is better established in week one than in month four.
There is no source-code escrow arrangement today. What exists instead is a continuity undertaking in our terms of service, published in these words: "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." Read the scope carefully — it is written for Resellers, and it commits to open-sourcing the platform to a stated level rather than to a general guarantee. If you are contracting directly rather than through a reseller, raise continuity and escrow during the assessment so it is addressed before signature rather than after.
What cutover day looks like
Migration runs in waves, not as one switch. Each migrated site arrives in your portal as a new trial site, which functions as an acceptance gate: your team reviews the migrated site against the original before anything is pointed at it. Sites are activated when they are accepted, not when the migration team says they are finished.
For the cutover itself we publish minimal downtime, typically less than an hour — our figure, per site, and worth confirming against your own DNS TTLs, because the DNS propagation you control is usually the longer half of that window.
The wave structure is what makes a large portfolio tractable. The organisation is not asked to accept four hundred sites in one afternoon, and the first wave is where the estimate for every subsequent wave gets corrected.
What to ask any platform vendor before you commit
Five questions, in the order that saves the most money:
- What exactly do you extract, named as a list? A vendor who answers "everything" has not done this at volume.
- Is custom functionality migrated or rebuilt? If the answer is migrated, ask which of your integrations they have already read.
- Who writes the redirect map, and when do we sign off on it? If this happens after content migration, your search equity is already at risk.
- Is this one agreement or one subscription per site? Ask procurement how many contracts they are willing to administer.
- Which region will our data sit in, and is it replicated anywhere else? Two questions, deliberately, and the second one is the one with an audit consequence.
Ask us the same five. We have also published a page on where WebinOne is the wrong choice, which names the cases where you should not buy this platform — read that before the feature list, because a vendor who cannot tell you where they lose is telling you nothing when they say they win.
If you have a portfolio that needs to move, the useful next step is the technical assessment, not a demo: bring your site list, however incomplete, and the integrations you know about. Get in touch and we will scope it against what is actually there.