How to Choose an Experience Platform That Fits Your Architecture and Skills

Chapters
Introduction
When your organization is searching for a new platform to deliver digital experiences, you need to carefully consider a vast selection of features that will fit into your existing architecture and skill set.
Of course, what your organisation requires differs depending on size and industry. However, based on 20 years of experience and inputs from our customers and partners, we have included the most important topics and common features you should consider.
Happy reading!
Chapter 1
Ensure the Platform Is Future-Proof
Vendor legitimacy
Make sure the vendor is legitimate and has a stable economy by investigating everything you can before continuing the procurement process. Check the vendor website, LinkedIn company profile, judicial data, business data, and testimonials.
Product maturity
Explore the community, documentation, source code, and quality systems to assess the maturity of the product. What version is it? What is the technical release frequency? How has the vendor solved previously reported future requests and bug fixes?
Development roadmap
Is there a roadmap available? Reading what is planned for the next months and years, as well as comparing what was scheduled to what was actually done can give you invaluable insights into the efficiency and reliability of the vendor.
Hybrid CMS
Don’t put all your eggs in one basket, whether it is a classic CMS or a headless CMS. Make sure the platform features a hybrid CMS, which provides classic solutions for editors and headless solutions for developers—with all alternatives being fully optional.
Product vision
Is the vendor a visionary with focus on flexible and agile work methods, and modern web technologies, or does it cling to legacy systems and business as usual?
Content primacy
The litmus test of discovering a true hybrid CMS fit for today’s and tomorrow’s omnichannel world. Make sure that the content is given primacy—that the platform presupposes flexible content types and structured content, as opposed to page building and presentation.
Beyond CMS: apps, APIs, etc.
Do you have other needs besides CMS, like apps and APIs? A future-proof platform should also support building customs services and APIs, as well as user-generated content.
Limitations
Check this if you have some pervasive limitations in your organisations, like integrations to legacy systems, CRMs, ERPs, design systems, or the choice of what front-end frameworks you can work with.

Chapter 2
Feature Check
What features do your project require? Make sure you do not forget anything with our handy checklist.
UX for editors
Content editors will work in the platform every day. Make sure it is user-friendly, with responsive design, clean organisation, and logical operations.
Headless possibilities
If you want to distribute your content in today’s fractured digital world, your CMS must support headless solutions through APIs.
Search
Retrieving content items makes it easier to find existing assets and re-use them in new settings. Your platform of choice should therefore include a fast and powerful search—complete with filtering options.
Localization
Trade and exchange of knowledge know no geographical boundaries. The possibility of offering localization of your digital experiences—different languages for different readers—should therefore be a feature.
Media handling
Digital experiences include much more than pure texts in today’s world. An experience platform should offer editing options for images, content management for documents, as well as easy embedding of e.g. videos.
Accessibility (for editors or end users)
Check this feature to ensure a thorough investigation of whether the potential experience platform supports accessibility standards and guidelines.
Enterprise-ready
Some enterprises have additional requirements catering to several stakeholders and marketing teams spread over the globe. Check each feature that applies:
- Multi-site
- Multiple users
- Complex roles and permissions
Personalization
Offering a personalised experience can make your business stand out on the market. If personalisation tools or integrations are essential, check this feature.

Chapter 3
Architecture
Now for the more technical stuff, the architectural requirements themselves.
Investments
How well does the potential experience platform fit in with the existing technologies of your organisation—essentially your heavy investments? Remember, not everything has to be thrown out on account of simply being old. Great and agile systems are still exactly that, regardless of age.
In any case, do research on how well the digital experience platform fit with your current technology, including, but not limited to:
- Framework
- Design system
- Integrations
- Programming tools
- Legacy systems
On premises vs. managed service
The question of hosting your digital experience platform on premises or by a managed service in e.g. the cloud is important due to concerns of security, maintenance, backups, scaling, and other issues from the world of DevOps
On premise
On premise keeps more control in the hands of your organisation, but can be more costly due to internal DevOps teams and hardware resources.
Managed service
A managed service offers no need for a deep understanding of backups, the basics of security, etc., with all of these being handled by DevOps professionals.
Open-source vs. closed source vs. cloud native
In addition to choosing an appropriate hosting solution for your organisation, you also need to consider another, somewhat overlapping aspect: the question of license and framework technology.
Open-source
An open-source solution is the most secure option and gives you full control, but can be costly depending on whether the tool is fully serviced and operated or not.
Closed source
A closed source solution allows the vendor to be in full control, but locks the customer in, while development and progress is solely dependent on the legal owner. Models vary greatly on closed source solutions, so be sure to assess them thoroughly.
Cloud native
Cloud native solutions are the same as SaaS, which can deliver great performance. However, they give the end user no control and makes him fully dependent on the vendor.
Suite vs. best of breed
Yet another architectural aspect to consider in regard to experience platforms is the type of solution your organisation will choose in terms of default features. A classical alternative is a full marketing suite vs. a best of breed, modular solution.
Full suite
A full suite is usually offered by large vendors, for large corporate customers. A full suite with everything you seemingly need from the start sounds promising, but be sure to thoroughly investigate how well integrated all the different features really are, as the vendors often come as a result of M&As.
Best of breed integrations
An alternative in the face of full marketing suites is a solution offering a flexible core and integrations with the best of breed features on the market. In this way, you can handpick separate systems for e.g. CRM, marketing automation, and SEO—whatever fits your requirements the best.
Continuous deployment
Do your potential vendors work by agile development principles and deliver continuous deployment of their solution, as opposed to waterfall processes and fixed release windows?

SDK
Is a software development kit included in the potential solution? What is required to start building, is it possible to run on all machines, how is the installation process, and can developers use their favourite editors in conjunction with the SDK?
Microservices
Microservices may be in the wind, but do your organisation really need such an architecture? And if “yes,” how does it fit with your current plan, and how do you wish to run services?
Use cases
While headless and hybrid CMS have been mentioned already, it is useful to envision a use case to really know exactly what solution your organisation needs.
Classic
A classic CMS is primarily meant for building and maintaining websites.
Headless
A headless CMS is primarily meant for apps.
Hybrid
A hybrid CMS is meant for both websites and apps.
Security
Experience platform security is essential for many reasons, including protection of customer data and your brand reputation. Check these in order to make sure security is on the agenda.
Hardening, battle tested
How well is the solution being tested? Has it been through several documented stress tests, demonstrably hardening its resilience towards threats?
Identity and access management (IAM)
How easy is it to delegate and revoke access to involved users in your organisation and third parties?
Quality
How is the quality system of the potential vendors? Make sure your vendor of choice has documented processes for every essential operation it commits to, including:
Automated testing
Is the solution tested automatically every day for bugs and critical issues?
Ease of use / complexity
How complex is the quality system to verify?
Performance
The performance of your digital experiences depend on a variety of factors, but which the underlying experience platform can contribute to enhance:
CDN
Does the vendor support a content delivery network model?
Local
Or is only local delivery possible with the setup?
Data storage
Is the solution based on NoSQL or a relational database? Relational databases might be a bottleneck or require more skills for management and tuning.
Scalability
Scaling your digital experiences is important to meet increased (or decreased) traffic demands in a secure, predictable, and affordable way. A cloud solution does not necessarily mean automatic scalability, so make sure to investigate this issue properly.
Resilience
How robust is the solution and how does it handle unexpected events? As usual, it boils down to what your organisation needs, and it is traditionally more expensive with higher demands. However, the cloud can solve many of these problems.
Routing
How do you manage the structure of your digital experiences? If you are opting in for a pure headless solution, no URL routing is available out of the box.
URL management
Usually associated with classic CMSs, for handling the URL of any given web page.
Routing app
As a headless CMS is a database with APIs, there is no inherent URL management. A dedicated routing app would instead be permissible.
Web server? Editors?
Other important routing topics can be solved with a hybrid CMS.
Chapter 4
Skills
The quality of your systems and their maintenance depend on the quality of your skill-sets.
Programming language fitting current skill-set
Even if a digital experience platform fulfils all your formal requirements, it can pose an insurmountable challenge if none of your developers have any experience with the underlying programming language.
Front-end framework
Make sure that your back-end experience platform is compatible with the language of your chosen front-end framework, in order to avoid platform illiteracy.
DevOps
Depending on whether the platform is fully managed or self-managed, you should ensure that your eventual DevOps possess the necessary skills as well.
Documentation and training
How easy is it to teach yourself and your co-workers the solution?
Developer availability
How widespread and known is the given solution on the market? Are there several agencies and developers available to assist implementation and maintenance?
Partner network
Does the vendor have a broad and robust network of qualified partners to assist your project?

Chapter 5
Proof of Concept
As a final note, we strongly recommend that your organisation issues a proof of concept (PoC). Conducting a PoC is superior to all the marketing gimmicks and demos in the world. In a PoC, you get a working product in an effort to solve the special requirements of your organisation, and you can really get your hands dirty and try before you buy.
Every vendor can perform a great demo, and thus it might not be the best way to learn about a given product. Issuing a PoC, however, enables you to learn as much as possible about the solution and how it can fulfil your requirements.
