Governance
Approvals, audit trail and sign-off gates are built into every wave, not bolted on afterwards. Nothing moves without a named owner accepting it.
The Banyan Method is our proven DXP replatforming process. The new platform is built beside the live one and runs in parallel until it is load-bearing, and then you choose the moment of switch. No big-bang cutover, no business-offline window.
A US insurer with around 19,500 staff moved its full estate onto Magnolia with a TBSCG-managed team working beside their own engineers. Delivery ran in nine accelerating waves, and the first sites were live within three months. By wave five their team was running the cadence in-house. That is what sovereignty looks like in practice.
Every migration is sized up front and priced fixed, upon completion of the discovery and planning session.
Six questions. You get a size and a readiness verdict before anyone calls you.
Up to 250 pages and 8 components, migrated in six weeks by the migration team. Training and warranty included.
Up to 1,000 pages, 20 components and one customised application, carried across in twelve weeks. Training and warranty included.
Multi-site estates with applications, SSO and integrations, delivered in waves over sixteen weeks and beyond. The Hartford ran this way.
A banyan tree drops aerial roots that become new trunks. When the original trunk dies back, nothing collapses, because the tree is already standing on what came next. A replatform done properly works the same way.
In practice, the legacy platform keeps running while the new one is brought up beside it, so the business is never resting on an unproven system. Senior engineers do the work itself rather than managing a graduate pyramid from a distance, and the parallel period ends on your signal, on a date your team chooses, once the new platform is carrying real load.
You'll have a parallel period with both running side by side. You decide the touchpoint. You're in control.
Fig 1 · The Banyan Method — Five stages. The new platform rises to load-bearing while the legacy platform keeps running, and the switch happens when you say so.
Approvals, audit trail and sign-off gates are built into every wave, not bolted on afterwards. Nothing moves without a named owner accepting it.
Languages and locales move with the content. Translation workflow is wired in from the first wave, so multilingual estates arrive whole.
Every piece of content passes through our own vendor-neutral interchange format, so nothing is ever trapped in either platform. It is the reason the parallel window works.
Content and assets are reshaped for the new platform on the way through: templates, components, renditions and metadata, mapped and verified.
We will not tell you a migration is one click, because it is not. AI accelerates the mechanical steps, and only those: mapping the estate, scaffolding components, moving content through the interchange, checking parity while both platforms run. The judgement about what moves, when and in what shape never leaves our engineers.
The work itself is done by our people and our process: a senior bench that has moved enterprise estates for twenty years, inside the governance that enterprises rely on. Everything the tooling produces is reviewed by a senior engineer before it ships.
This programme is built around CMS migration first, and the pricing above is sized for content platforms. The method itself does not mind what kind of platform is moving. The same parallel build and wave delivery have carried asset libraries and commerce stacks, because the thing being protected is the same: a live business that cannot go offline.
Old and new run in parallel until the new platform is carrying real load. Then you choose the moment, and at the end of the engagement your team runs the platform without us. Sovereignty is the point.
Most of our migration work happens inside financial services, insurance and other regulated estates, where a business-offline window is not an option and every change needs an audit trail. That is the environment the Banyan Method was shaped by, and it is why the method starts from the assumption that the live platform must keep running.
The new CMS is built alongside the live one and runs in parallel until it carries the business on its own terms. There is no big-bang cutover. You decide when to switch, with the legacy platform still running as a safety net until you do.
You do. The parallel period ends on your signal, not on a vendor schedule. Both systems run concurrently until your team is satisfied the new platform is load-bearing, and the cutover is sequenced on the date you choose.
Work that used to run across two or three quarters now runs in weeks. A phased AI toolchain compresses the repetitive lift across every stage, while senior engineers do the strategic work. The parallel period itself is sized to your risk appetite, not shortened to hit a deadline.
No. The legacy platform keeps running throughout. The new platform is brought up beside it and validated under real conditions before anything is switched. A parity monitor compares both systems during the parallel window so regressions surface before users notice them.
Your team is trained on the live system they will actually run, not on generic platform behaviour. By the final stage you are self-sufficient by design. A clean handoff into Canopy support or a Grove partnership is available if you want it, but it is optional, because sovereignty is the point.
Migrations come in three fixed-price sizes: Small starts from £59k for a division or campaign site over six weeks, Medium from £200k for a working estate over twelve weeks, and Large programmes are scoped on their own terms and delivered in waves. Final pricing is confirmed after the discovery and planning session, and the two-minute readiness check gives you the size before anyone calls you.
Old and new running in parallel until the new is load-bearing. You choose the moment of switch, and you run the platform without us at the end. That is the whole point.