5 critical questions to ask your CMS integration partner
Integrations can boost your CMS capabilities, or become a long-term liability. To reduce the risk of bad integrations, dig a little deeper than the one-liner answers.
In a previous post, I argued that "Sure, we have a module for that!" isn't a good enough answer when it comes to integrations between the CMS and other systems.
Clients should expect a minimum of additional details from the CMS integrator about how the proposed integration (a plugin, module, framework, web service, etc) can solve their current - and hopefully future - business needs.
Getting the integration details
CMS integrators should be able to answer questions like:
- What kind of integration is it?
Is it a web service, a REST API, a pre-built DLL, a native Windows application, or what? What kind of data formats can it handle?
This will give you an indication of how we can integrate the module with the CMS, how we can communicate with it, and any technical requirements for the environment it will be used in. - Which versions of ["System X"] are supported by the integration?
Does the integration support the latest version, or is it still locked to a legacy one? Is it even backwards compatible with older versions so we don't HAVE to upgrade to the latest version of System X?
Are there plans to further develop the integration to leverage new features of System X? - What kind of dependencies does the integration have?
Is the integration built for a specific CMS (if yes, which version?) Is is completely standalone (e.g. a web service), or do we have to weave it into the source code of our project? Will we be able to substitute System X with System Z as a data provider in the future?
Note: That last question warrants some explanation, as it addresses the architecture of the integration. For instance, a web site might be integrated with Dynamics CRM to retrieve a list of courses that users can sign up for. Let's say all the courses are then migrated to Salesforce CRM. To avoid having to rewrite the entire communication layer of the site, the integration should be architected in a way that the CMS still calls the same generic interface method (e.g. GetCourses), being unaware that the course data is now provided by a different external system than before. - How flexibly can the integration handle new requirements?
Inevitably, business needs will change over time. Will we be able to customize the integration to support new specific requirements, or will the integration only support generic, one-size-fits-all features? If the client ever switches CMS integration partners, will they continue to support this integration (or supply the new integrator with the source code?) - What are some comparable reference cases that use this integration?
Unless you're breaking new ground, integrators should be able to show comparable references and explain how they're leveraging the integration. Serious integrators will also be transparent with potential pitfalls or limitations that might be of relevance to the client.
Ask about licenses and maintenance
In most sales bids, CMS implementers are required to state any incurring license costs upfront. If any of the integration modules/frameworks they propose have a license/subscription fee, that should be detailed in their bid.
This applies both to integrations provided by the CMS implementer, and official Episerver add-ons (all Episerver associated partners have access to the price lists for those.)
What is not always apparent though, is who will pay for continuous maintenance of integrations:
- If the integration is tailored for each individual client, expect that you, the client, will have to pay for that.
- If the integration is shared by several clients, and further development is driven mainly by requests from those clients, expect that the client making the change request will have to pay for that. However, new features added may then become available for all the clients.
- If the module is shared by several clients but not tailored to any specific client, the CMS integrator might cover the maintenance cost themselves.
At Epinova, we do tons of CMS integrations, big and small. Being specialists in Episerver, we are happy to use our experience to give straight answers - even when that means challenging clients' preconceptions, serving a reality check, or discouraging certain integrations altogether if necessary. You should expect no less from your own integration partner.