Re-platforming starts with a better platform decision.
A new platform should remove a real constraint. WebXd helps you compare the options, decide what stays, and implement the agreed website transition. We connect the choice to your publishing needs and the systems around the site, so the destination makes sense for the people who will use and maintain it.
Write down what the current platform prevents.
Start with a task your team cannot complete reliably. Perhaps a resource needs approval in two departments, or every new location requires a template change. Record the task and the workaround before choosing a replacement. That gives the platform comparison something specific to answer.
The cause matters. An unclear content model or an unused setting may be fixable where you are. A required connection that the platform cannot support may justify a move. We assess those possibilities together and document the reason for staying, extending, or changing platforms.
Useful evidence to bring
- A blocked taskShow the actual update, approval, or visitor journey that causes trouble.
- The present workaroundIdentify manual copying, restricted access, or a dependency on custom code.
- The required behaviorDescribe what the task must do and who needs to complete it.
Compare the work, then compare the platforms.
A feature name is only the start of a comparison. Test how the feature works with your content and permissions. A managed platform, a traditional CMS, and a separate frontend can all suit different needs. Their operating costs and development responsibilities belong in the same discussion as their editing tools.
Consider Northline Learning, a fictional resource portal. Its editors need to reuse course information, while members sign in through an existing identity provider. The comparison below turns those requirements into proof requests. A vendor demonstration becomes more useful when it follows the team's own tasks.
| Requirement | Dependency to check | Evidence to request |
|---|---|---|
| Reuse a course description | Structured content and relationships | Edit once; inspect every place it appears |
| Approve a public resource | Roles and publishing workflow | Editor drafts; reviewer approves; permissions hold |
| Open a member resource | Identity provider and access rules | Allowed and denied users try the same link |
| Route a course inquiry | Form fields and CRM connection | Submit a sample; verify the receiving record |
For each candidate, record what is native, what needs configuration, and what requires a paid extension or custom work. Check current plan terms and export options directly with the provider. An attractive interface does not establish whether your information can leave the platform later.
Give every dependency a keep or change decision.
Changing the website platform does not automatically require replacing every connected system. Your domain, useful page designs, content, and identity provider may remain. Each retained dependency still needs a compatibility check. We map the connections and identify the parts that need an adapter, a new implementation, or a separate decision.
In the Northline concept, the identity provider stays, the publishing system changes, and the CRM connection is adapted. The register also leaves an approval-workflow question open until a pilot proves it. Unresolved requirements remain visible instead of quietly becoming assumptions in the build.
- RetainKeep the domain and identity provider; verify access and account ownership.
- ReplaceBuild the agreed content model and publishing experience on the selected platform.
- AdaptMap the inquiry fields and test the connection to the existing CRM.
- ResolveProve the approval workflow before committing the portal to the move.
We turn the approved decisions into implementation work: target configuration, reusable templates, agreed content transfers, and connected workflows. A redesign or new feature set can be included when it has a defined purpose. It receives its own scope so the platform move remains reviewable.
Choose an operating model your team can own.
The destination changes more than the editing screen. Someone must manage accounts, review updates, approve releases, and investigate a failed connection. A hosted service may take on some infrastructure work while leaving configuration and content responsibilities with you. We identify those boundaries before the platform becomes the live home of the site.
Document the people or roles responsible for routine publishing and technical changes. Include who holds subscriptions and credentials, who can restore service, and where requests should go. Your team should be able to find those answers without reconstructing the project from old meeting notes.
| Work | Decision needed |
|---|---|
| Publishing | Who drafts, approves, and corrects live content? |
| Platform changes | Who reviews extensions and authorizes a release? |
| Accounts and licenses | Which organization owns each account and renewal? |
| Recovery and connections | Who investigates failures and verifies restoration? |
The comparison should include recurring licenses, hosting, maintenance, and the effort of everyday changes. These costs depend on the selected platform and agreement. We also plan documentation and training around the tasks your team expects to own, with further support defined in the proposal.
Decide how long two platforms need to coexist.
Some sites can move in one planned cutover after rehearsal. Others need a section to run on the new platform while the rest remains in place. A phased approach only helps when the boundaries are workable. Shared navigation, accounts, and live data can make temporary overlap more complex than it first appears.
We choose the transition around those dependencies and your publishing calendar. Agree where new edits happen, how late changes reach the destination, and when the source stops accepting changes. A recovery plan also needs to account for records created after the switch; routing traffic back alone may not restore a consistent system.
Accept the new platform with a record of proof.
The website loading is one check among several. Editors need to publish real-shaped content, visitors need to complete important tasks, and connected systems need to receive the right records. We agree the acceptance evidence before implementation, then record the findings and exceptions against those requirements.
For changed URLs, check the intended destination and its response, then review redirects, internal links, and indexing controls. For retained URLs, verify that the same address still delivers the expected resource. Search monitoring continues after launch because search systems need time to process significant changes.
- Content: representative records, media, and relationships match the agreed mapping.
- Tasks: publishing, member access, and inquiry routing behave as specified.
- Operations: account access, release instructions, and recovery steps have owners.
- Exceptions: open issues have an accepted disposition or block the switch.
- Retirement: exports, retained records, old redirects, and contract decisions are accounted for.
Retire the old system only when the agreed checks and retention decisions support it. Keep the decision register, configuration notes, and acceptance record with the handoff. They explain why the platform was chosen and give the next person a starting point for changing it.
Settle the questions that change the scope.
Do we need to choose the new platform first?
You can begin with the current site's constraints and a shortlist, or with no destination selected. We can scope an assessment around the requirements and evidence needed to choose. If the platform is already chosen, we review the fit and unresolved dependencies before defining the implementation.
Is re-platforming the same as application re-engineering?
Here, re-platforming covers the website's move between platforms and the work needed to make that destination usable. Application re-engineering focuses on improving the internals of an existing application. A project may need both, but those responsibilities and acceptance checks should be defined separately.
Can we keep the design and protect search visibility?
Useful designs and URLs can often be retained, subject to the destination's constraints. We plan route mapping and technical checks where changes are required. Search rankings can fluctuate during a move, so continuity work reduces avoidable problems without promising that rankings will remain unchanged.
What determines the estimate and schedule?
The proposal depends on content models, connections, access rules, and the chosen transition. Export restrictions or a difficult shared dependency can change the effort substantially. Bring your current site and any fixed dates; we identify the unanswered questions before committing to the delivery scope.