Skip to main content
How to Choose an Experience Platform That Fits Your Architecture and Skills Cover

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


When your organisation 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!
Vegard Ottervig, Head of Content, Enonic

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.
Archive Search


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.
  • Localisation

    Trade and exchange of knowledge know no geographical boundaries. The possibility of offering localisation 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

  • Personalisation

    Offering a personalised experience can make your business stand out on the market. If personalisation tools or integrations are essential, check this feature.
Magnifying Glass Search



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.


    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?
Digital Team Problem Solving
  • 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.


    A classic CMS is primarily meant for building and maintaining websites.


    A headless CMS is primarily meant for apps.


    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:


    Does the vendor support a content delivery network model?


    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.


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?
Team Meeting


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.

Team Mobile Phone


Want this Checklist on the go?

Simply download the PDF. No registration required.