Describe where you are. See how the move is framed.
A version upgrade is a technology event. A transformation is what happens to the people, the operating model, and the architecture around it. Set out your platform, your current version, the version you intend to reach, and the shape of your deployed estate.
A version number is not a transformation plan.
Most platform moves are scoped as a technical migration and then stall on everything that was never technical. HBT frames the move across all three orbits before a single environment is built.
The estate is older than the plan
Customisations, workflows, and integrations accumulated over a decade rarely appear in the migration scope until they block it.
Ownership is unclear
Content, permissions, and processes have owners who have moved on. Nobody can approve what should carry forward and what should not.
The target is assumed, not chosen
The newest version is treated as the destination without asking which capabilities the organization actually intends to operate.
The move is framed across the three orbits, not just the platform.
The same three orbits that govern every HBT engagement govern a platform transformation. Each one carries decisions that a purely technical migration plan leaves undecided.
Human orbit
Who carries the change
- who owns which content and process after the move
- what changes in the daily experience of the people using it
- the capability gap between the current and target platform
- adoption, training, and the support model on day one
Business orbit
What the move must protect
- processes and approvals that cannot pause during the move
- records, retention, and compliance obligations that travel with the content
- decision rights over what is migrated, rebuilt, or retired
- the measures that define whether the move succeeded
Technology orbit
How the estate actually moves
- the supported upgrade path and its intermediate hops
- customisations, integrations, and their target equivalents
- identity, access, and security patterns on the target platform
- environment topology, cutover sequence, and rollback position
Five movements from current state to steady state.
01
Assess
Inventory the deployed estate, its customisations, integrations, and the processes running on it. Establish what is genuinely in use.
02
Map
Decide, with named owners, what migrates as-is, what is rebuilt on target capabilities, and what is retired. This is a business decision, not a technical one.
03
Prepare
Stand up the target topology, remediate blockers, resolve the upgrade path including any intermediate versions, and rehearse the move.
04
Move
Execute in sequenced waves with a defined rollback position, keeping the processes that cannot pause running throughout.
05
Stabilise
Hand over ownership, close the capability gap through enablement, and confirm the measures agreed at the mapping stage.
This is the recommended HBT transformation model. It is presented as a direction, not as a fixed contractual delivery method.
Pick your technology stack.
Choose the platform the transformation is centred on. The version path and estate questions that follow adapt to it.
Set the version path.
Select the version you have deployed today, then the version you intend to reach. Only versions ahead of your current one can be chosen as a target.
Choose a technology stack above and the version path for that platform will appear here.
Versions covered
SharePoint
SharePoint Server 2010 · SharePoint Server 2013 · SharePoint Server 2016 · SharePoint Server 2019 · SharePoint Server 2021 SE · SharePoint Online
Sitecore
Sitecore 6.0 · Sitecore 6.1 · Sitecore 6.2 · Sitecore 6.3 · Sitecore 6.4 · Sitecore 6.5 · Sitecore 6.6 · Sitecore 7.0 · Sitecore 7.1 · Sitecore 7.2 · Sitecore 7.5 · Sitecore 8.0 · Sitecore 8.1 · Sitecore 8.2 · Sitecore 9.0 · Sitecore 9.1 · Sitecore 9.1.1 · Sitecore 9.2 · Sitecore 9.3 · Sitecore 10.0 · Sitecore 10.1 · Sitecore 10.2 · Sitecore 10.3 · Sitecore 10.4 · Sitecore 10.5
Describe the deployed estate.
How many servers carry each part of the system you are running today. This is what determines whether a move is a topology change or a rebuild.
Select the version you have deployed today and the roles for that version will appear here.
Roles captured, by deployment era
SharePoint Server 2010
Web Front-End · Application · Search · SQL Server · Office Web Apps
SharePoint Server 2013 – 2016
Web Front-End · Application · Search · Distributed Cache · Workflow Manager · SQL Server · Office Web Apps
SharePoint Server 2019 – 2021 SE
Web Front-End · Application · Search · Distributed Cache · SQL Server · Office Online Server
SharePoint Online
Site collections · Hub sites · Content volume (TB) · Named users · Custom solutions
Sitecore 6.x
Content Management · Content Delivery · SQL Server · Search index
Sitecore 7.x – 8.x
Content Management · Content Delivery · Processing · Reporting · xDB collection · SQL Server · Search index
Sitecore 9.x – 10.x
Content Management · Content Delivery · Processing · Reporting · xConnect Collection · Marketing Automation · Identity Server · Solr / SearchStax · Redis session · SQL Server
Your blueprint so far.
A summary of what you have described. Share the link to this page and the selections travel with it.
Complete the steps above and your blueprint will be summarised here.
This summary is an indicative framing of the transformation, not a migration assessment, quote, or delivery commitment. Supported upgrade paths, intermediate versions, and effort are confirmed only after a formal assessment.
Bring the blueprint to a conversation.
Send the outline of where you are and where you intend to go, and HBT will frame the appropriate assessment across the three orbits.