Risk Checklist for Staying Composable with Sitecore

What Your Leadership Will Actually Ask

At Sengo, we have led composable implementations at iA Financial Group, Fonds de solidarité FTQ, and Cirque du Soleil, and we have run more than 50 platform audits across eight CMS and DXP vendors. Across those engagements, the same five risks come up almost every time. Furthermore, the same five mitigation patterns work — provided you name the risks first and design for them deliberately. This article walks through each one, then closes with a checklist you can take into your next steering committee.

Risk 1: Vendor Support Maturity

The first of the composable DXP risks is the maturity of the vendors you are stitching together. A bundled Sitecore stack gives you one support contract, one escalation path, and one account manager. A composable stack gives you five to ten of each. Some of those vendors are large and stable. Others are Series B startups with a brilliant product and a 12-person support team. When something breaks at 2 a.m., that difference matters.

The mitigation is not to avoid newer vendors. It is to tier them. Classify every vendor in your composable architecture as Tier 1 (mission-critical, 24/7 SLA required), Tier 2 (important, business-hours support acceptable), or Tier 3 (replaceable within 30 days). Then negotiate accordingly. Moreover, insist on data export rights and documented APIs for every Tier 3 vendor so a swap is a project, not a crisis. Reference the MACH Alliance vendor directory as a starting point for vendor diligence — members commit to interoperability standards that reduce lock-in risk.

Risk 2: Upgrade Burden Across the Stack

Sitecore bundle proponents love to point out that a composable stack has many moving parts, each with its own release cadence. They are right. This is one of the composable DXP risks that quietly compounds over time. A headless CMS pushes a breaking schema change. The search vendor deprecates an API endpoint. The CDP rolls out a new event format. Suddenly your team is firefighting four upgrades in a quarter instead of one large upgrade every two years.

However, the mitigation is structural, not heroic. First, build an integration layer — a thin BFF (backend-for-frontend) or middleware tier — that absorbs vendor changes before they reach your application code. Second, subscribe to every vendor’s changelog and assign an owner per integration. Third, allocate a fixed percentage of every sprint (we recommend 15%) to integration maintenance. As a result, upgrades become routine hygiene rather than emergency projects. At iA, this discipline kept a six-vendor composable stack stable through two full years of independent vendor releases.

Risk 3: Integration Drift Over Time

Integration drift is the most underestimated of the composable DXP risks. On day one, your architecture diagram is clean. Each service has one job, the contracts are documented, and data flows are explicit. Two years later, someone has added a Lambda that pulls from the CMS, transforms the payload, and writes to the CDP — without telling anyone. Multiply that by a dozen quiet workarounds and your composable stack becomes harder to reason about than the monolith you replaced.

The mitigation is governance, not tooling. Maintain a living architecture decision record (ADR) for every integration. Require pull-request review from a designated architect for any change that crosses a service boundary. Additionally, run a quarterly architecture review where the team walks the current diagram and flags any drift from the documented design. Gartner’s definition of composable business emphasizes governance as a first-class concern, not an afterthought — and the teams that take this seriously avoid the brittle-stack outcome.

Risk 4: Team Capacity and Specialization

A monolithic Sitecore implementation can be run by a team of generalists who know one platform deeply. A composable architecture demands specialists — or at least generalists with strong API integration instincts. This is one of the composable DXP risks that hits hardest at mid-market organizations where the team is already stretched thin. If your architects are also your developers and your DevOps engineers, adding five vendors to the mix can break the team before it breaks the stack.

The mitigation is to be honest about capacity before you commit. Map each vendor in the proposed stack to a named owner on your team. If any vendor lacks an owner, you have a gap to fill — through hiring, training, or a managed-service partner. At Fonds de solidarité FTQ, we worked with the internal team for six months before go-live to ensure every component had a clear owner and a documented runbook. Consequently, the team felt ownership of the stack from day one rather than dependency on outside consultants.

Risk 5: Cost Defensibility vs Bundle Pricing

The fifth risk is the one your CFO will raise first. A Sitecore bundle quote is a single line item. A composable stack quote is a spreadsheet with 8 rows, 3 currencies, and consumption-based pricing on at least two of them. On the surface, the bundle looks cleaner and often cheaper. Therefore, defending the composable choice requires a side-by-side total cost of ownership (TCO) model that captures the costs the bundle hides — mandatory upgrade projects, customization debt, and the opportunity cost of slower delivery.

Build a three-year and five-year TCO model that includes licenses, implementation, integration maintenance, upgrade projects, training, and the cost of replatforming if the bundle hits a ceiling. In our experience, the composable stack is more expensive in year one and cheaper from year three onward — but only if you have actually budgeted for the integration maintenance in Risk 2. Be honest about this in your model. A defensible TCO that shows composable losing in year one and winning by year five is far stronger than an optimistic model that loses credibility with finance.

How to Defend Composable to the Board

When you walk into the board meeting, lead with the composable DXP risks, not the benefits. Counterintuitively, this builds credibility faster than any architecture diagram. Acknowledge each risk, show your mitigation, and quantify the residual exposure. Boards trust architects who name the downsides and have plans for them. Conversely, they distrust pitches that sound too clean.

Tie each risk back to a business outcome the board cares about: time to market, total cost of ownership, vendor lock-in exposure, and team retention. Use the proof points you have — for us, that is composable implementations at iA, FTQ, and Cirque du Soleil, two Sitecore MVPs on staff, and 50+ vendor-neutral audits across the major platforms. Your proof points will be different, but the structure is the same: real implementations, named risks, named mitigations, and honest numbers. For deeper context on the broader Sitecore decision, see our pillar guide on the Sitecore AI decision.

The Risk Checklist

Use this checklist before your next steering committee. If you cannot answer yes to every item, you have work to do before defending the composable choice.

• Vendor tiering complete: Every vendor in the proposed stack is classified Tier 1, 2, or 3 with documented SLAs and exit criteria.
• Integration layer designed: A BFF or middleware tier absorbs vendor changes before they reach application code.
• Upgrade budget allocated: 15% of every sprint is reserved for integration maintenance and vendor changelog response.
• Architecture decision records live: Every cross-service integration has an ADR, and a quarterly review process is scheduled.
• Owners named per vendor: Every vendor in the stack has a named internal owner with documented runbook access.
• TCO model built: Three-year and five-year TCO comparisons exist, signed off by finance, with composable’s year-one disadvantage acknowledged.
• Exit plan documented: For every Tier 3 vendor, a documented swap plan exists with estimated effort and data export procedures.
• Board-ready risk register: All five composable DXP risks appear in the risk register with owner, mitigation, and residual exposure.

If you want an outside read on your stack before the board meeting, we run vendor-neutral assessments designed for exactly this situation. See our composable DXP solution page or browse customer success stories for examples of how other enterprise teams defended their composable choice.

Ready to pressure-test your composable architecture before leadership does?