The Enterprise WordPress Playbook [01ky2wznmxv6fwe11jv40n00ns]

The Enterprise WordPress Playbook 🔗 **Source:** [The Enterprise WordPress Playbook](https://25686187.fs1.hubspotusercontent-eu1.net/hubfs/25686187/White%20Papers/The%20Enterprise%20WordPress%20Playbook%20%E2%80%94%20A4%20layout%20(compressed).pdf) > [!note]+ Document Notes > tags: [enterprise-wordpress, composable-architecture, total-cost-of-ownership, governance-and-compliance, ai-publishing-workflows, vendor-lock-in] > author: [MISSING] > source: Human Made > reference: https://25686187.fs1.hubspotusercontent-eu1.net/hubfs/25686187/White%20Papers/The%20Enterprise%20WordPress%20Playbook%20%E2%80%94%20A4%20layout%20(compressed).pdf > date created: {{date:YYYY-MM-DD}} {{time:HH:mm}} > > # 🏷️ Title: The Enterprise WordPress Playbook >  ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [Source PDF](https://25686187.fs1.hubspotusercontent-eu1.net/hubfs/25686187/White%20Papers/The%20Enterprise%20WordPress%20Playbook%20%E2%80%94%20A4%20layout%20(compressed).pdf) - [WordPress.org Showcase](https://wordpress.org/showcase/) - [WordPress Security Team](https://make.wordpress.org/core/handbook/testing/reporting-security-vulnerabilities/) - [Accessibility in WordPress](https://wordpress.org/about/accessibility/) ## 📝 Summary - Human Made, a WordPress enterprise agency (maker of Altis and Accelerate), published a 13-chapter vendor whitepaper arguing that WordPress should be evaluated as a strategic, business-critical platform rather than a tactical CMS choice for large organizations. - It matters because it's aimed at buying-committee readers (CTOs, CFOs, digital leaders) weighing WordPress against proprietary enterprise CMSs during a platform decision, and it frames the "build vs. buy vs. evolve" question in WordPress's favor. - Key stakeholders: enterprise technology leaders, CFOs (TCO/ROI framing), governance/compliance teams, distributed editorial and engineering teams, and implementation partners (with Human Made positioned as the "right partner"). - Risks and tradeoffs it acknowledges only lightly: proprietary lock-in is treated as the main risk to avoid, while WordPress-side risks (plugin/ecosystem quality variance, in-house expertise requirements, integration governance overhead) are mentioned but not weighed with comparable rigor. - Bottom line: the document is a structured sales argument — well organized and directionally reasonable on TCO/flexibility trends, but every comparison resolves toward "choose an open, WordPress-based, Evolve-style platform" and, implicitly, toward Human Made/Altis as the implementation partner. ## 📖 Main Content - **Framing (Ch. 1–2):** Enterprise digital platforms now serve multiple brands/regions/languages simultaneously, with distributed teams under pressure to move fast and cut cost at once. The playbook argues platform choice has shifted from a tooling decision to a "business-critical" one, and that composability/interoperability are now required to keep pace. - **Why WordPress (Ch. 3):** Leans on adoption stats (43% of "the internet," unspecified methodology — almost certainly the W3Techs CMS-market-share figure, not literal internet share) and ecosystem depth as proxies for enterprise readiness, plus a case-study pointer (AGBI) as evidence of real-world delivery. - **AI (Ch. 4):** Centers on WordPress 7.0's new "AI Client" as a standardization layer for connecting to AI providers — used for content summarization, metadata/SEO assistance, editorial analytics, personalization, and AI-assisted taxonomy/tagging. Frames governance (review steps, prompt management, audit trails) as buildable into the workflow rather than bolted on. - **TCO (Ch. 5):** Core argument is that proprietary CMS costs front-load into licensing and then compound through vendor-controlled customization and step-function pricing tiers, while open-platform costs shift into engineering investment that scales more predictably with actual need. This is the strongest, most falsifiable claim in the document — and also the one with zero supporting numbers. - **Governance/Security/Compliance (Ch. 6):** WordPress security is reframed as primarily an operational/configuration concern (hardening, patching cadence, monitoring) rather than a core-platform one. WordPress Multisite and role-based permissions are positioned as the mechanism for centralized governance with local editorial autonomy. GDPR, accessibility, and localization are named as compliance surfaces WordPress "can support," without detail on how. - **Build vs. Buy vs. Evolve (Ch. 7):** Introduces a three-path framework where "Evolve" (open, incremental, WordPress-style) is presented as structurally superior to both bespoke builds (high upfront cost, expensive to adapt) and proprietary buys (vendor-controlled roadmaps, licensing creep). Migration is reframed as a continuous, phased practice rather than a one-time event. - **Composable Architecture (Ch. 8):** WordPress positioned as the content/editorial layer in a wider stack (DAM, CDP, analytics, commerce), connected via REST/GraphQL APIs, webhooks, and middleware. Covers four recurring architecture patterns: integrated core CMS, headless/decoupled, multisite-with-shared-services, and hybrid. - **Scaling Teams (Ch. 9):** Addresses multi-brand/multi-region/multilingual operations, editorial workflow customization, developer experience, and CI/CD-style operating models (version control, automated testing/deployment, staging, release processes) as the human-side counterpart to the architecture chapter. - **Performance/Reliability (Ch. 10):** Describes a fairly standard enterprise WordPress hosting stack — CDN edge caching, object caching, autoscaling, observability (APM, infra metrics, Core Web Vitals), disaster recovery (backups, rollback, multi-region failover), and demand-spike handling — explicitly tied to Human Made's own Altis platform as the reference implementation. - **Future-Proofing (Ch. 11):** Argues open ecosystems reduce long-term technology risk versus vendor lock-in, and ties platform "sustainability" to block-based development and Full Site Editing as mechanisms that reduce technical debt. - **Getting Started (Ch. 12):** Practical playbook for adoption: assess current platform maturity, find quick wins (workflow improvements, site consolidation, design systems, performance), build a cross-functional business case, and follow a four-phase roadmap (discovery → pilot → rollout → ongoing evolution). Includes explicit partner-selection criteria that double as an implicit pitch for Human Made. - **Conclusion (Ch. 13):** Restates the core thesis — platform decisions are long-term strategic investments, and the strongest platforms combine modular architecture, scalable governance, integrated ecosystems, and continuous iteration over one-off transformation. ## 🗒️ Notes - The 43%-of-the-internet claim (Ch. 3) is repeated without a citation or methodology note; treat as an industry-standard talking point (commonly sourced to W3Techs CMS market share) rather than a verified figure in this document. - The TCO chapter (Ch. 5) is the document's central persuasive claim and its weakest evidentially — every comparison ("licensing fees increase as usage grows" vs. "costs are driven by infrastructure and engineering choices") is qualitative, with no cost bands, case studies, or ranges given, despite the chapter explicitly being framed for CFO readers. - Security framing (Ch. 6) is technically defensible — WordPress core's own security posture *is* largely a function of configuration, hosting, and patch discipline — but the document doesn't address the plugin/ecosystem attack surface, which is the more commonly cited enterprise WordPress security concern. - The "Build vs. Buy vs. Evolve" framework (Ch. 7) is presented as an objective three-path taxonomy, but "Evolve" is definitionally WordPress/open-source in this document, making the "choice" circular by construction. - Every product callout box (Accelerate, Altis, the Definitive Guides on Multisite/Migrations/Headless, the stakeholder-pitch guide) is a Human Made asset — the whitepaper functions as a hub linking to a deeper Human Made content/sales funnel. - The AI Client (Ch. 4, 11) is real and current: WordPress 7.0 did ship first-class AI provider abstraction, so this section is more verifiable than the TCO claims, though "governed at scale" is asserted rather than demonstrated. - The AGBI case study (Ch. 4.2) is the only concrete, named third-party proof point in the entire document — everything else is generic "organisations" language. ## 📚 References - [WordPress.org Showcase](https://wordpress.org/showcase/) — referenced as evidence of enterprise adoption - [Human Made case studies](https://humanmade.com/case-studies/) — referenced re: enterprise delivery track record - [Altis Cloud](https://www.altis-dxp.com/) — Human Made's enterprise WordPress hosting platform, referenced throughout Ch. 10 - [WordPress Security Team](https://make.wordpress.org/core/handbook/testing/reporting-security-vulnerabilities/) — referenced re: vulnerability handling - [Accessibility in WordPress](https://wordpress.org/about/accessibility/) — referenced re: compliance support - humanmade.com — publisher ## 🗣️ Paraphrase - Human Made's pitch is that enterprise platform decisions used to be a back-office tooling call and are now a front-office strategic one, because organizations run many brands, regions, and channels through the same system while teams demand faster iteration and lower cost simultaneously. Their answer is that flexibility beats short-term simplicity: proprietary systems win on day-one predictability but lose over time as licensing tiers, vendor-controlled roadmaps, and constrained integrations accumulate hidden cost and slow response to change. - The practical argument threads through cost (engineering investment scales with actual need instead of licensing tiers), governance (centralize standards, decentralize execution via Multisite and role-based permissions), architecture (WordPress as the content layer in a composable stack rather than a monolith), and AI (WordPress 7.0's AI Client as a standardized, governable integration point). The adoption path they recommend is incremental — assess, pilot, expand, iterate — explicitly avoiding one-time "big bang" migrations, with partner selection (implicitly, Human Made) framed as the deciding factor in whether that flexibility gets realized or squandered. ## 📰 Newsletter Enterprise teams eyeing a platform switch have a new 70-page argument to chew on: Human Made's *Enterprise WordPress Playbook* makes the case that WordPress earns its enterprise seat not through nostalgia but through composability — REST/GraphQL APIs, Multisite governance, and (as of WordPress 7.0) a standardized AI Client for plugging in AI providers without one-off integrations. The TCO chapter is the one worth debating with your finance team: it argues open platforms trade licensing-fee predictability for engineering-cost control that scales with actual need rather than vendor tiers — directionally sound, though the paper offers no numbers to back it. Worth a skim if you're building the business case for a WordPress migration, and worth cross-checking against a non-vendor source before you cite the TCO chapter in a board deck. ## ✅ Action Items #### DevRel - Developer experience: none surfaced directly, though the whitepaper's repeated references to "Definitive Guides" (Multisite, Migrations, Headless) suggest Human Made's own DevRel content funnel is the intended next step for readers. #### OSPO - Policy & Governance: the whitepaper's governance chapter (curated plugin/dependency lists, pre-adoption security review, update visibility) maps directly to a standard OSPO plugin-governance policy — worth adapting if evaluating WordPress at enterprise scale. - Security Management: "conducting security reviews before adoption" and "maintaining visibility over updates and changes" (Ch. 6.3) are concrete, adoptable OSPO practices. #### Community - Not addressed in this source — the document is vendor/buyer-facing, not community-governance-facing. #### WordPress - Core AI: the AI Client (WP 7.0) is the single most concrete, verifiable technical claim in the document — worth independent verification before citing it in an architecture decision. - Hosting: the Ch. 10 performance/reliability checklist (edge caching, autoscaling, observability, DR/failover) is a reasonable baseline requirements list for any enterprise WordPress hosting RFP, vendor-neutral despite Altis being the named example. - Accessibility: Ch. 6.3 gestures at WCAG-aligned compliance support but with no specifics — flag as a gap to fill before using this document as an accessibility compliance reference. #### The WPCC - Not addressed in this source. ### FAIR - Not addressed in this source — the whitepaper's "avoid vendor lock-in" argument is directionally aligned with FAIR's technical-independence goals but never engages with FAIR by name. ## 🧪 Hypotheses - H1: Organizations that adopt an "Evolve" (incremental, open-platform) migration strategy report fewer large-scale replatforming events over a 5-year window than organizations that adopt "Buy" (proprietary) strategies. - H2: Total cost of ownership for enterprise WordPress deployments is lower than proprietary CMS TCO at comparable scale, when engineering, hosting, and maintenance costs are fully loaded — not just licensing. - H3: Enterprise WordPress deployments using the WordPress 7.0 AI Client show faster time-to-integrate new AI providers than deployments using bespoke, provider-specific integrations. - H4: WordPress Multisite governance models (centralized standards + local editorial autonomy) produce measurably faster regional content velocity than fully centralized proprietary CMS governance, without proportional increases in compliance incidents. - H5: The plugin/ecosystem attack surface (not core WordPress) is the dominant driver of security incidents in enterprise WordPress deployments — meaning governance chapter recommendations (curated plugins, pre-adoption review) matter more to security outcomes than core-platform hardening. ### 📊 Methodology - H1/H2: comparative case study across matched enterprise organizations (similar size/industry) that migrated via Evolve vs. Buy strategies; track total platform spend (licensing + engineering + hosting + maintenance) and replatforming events over 5 years. - H3: time-and-motion study comparing AI Client integrations vs. legacy bespoke AI integrations across a sample of WordPress 7.0 adopters, controlling for team size and AI provider. - H4: mixed-methods study combining Multisite deployment logs (publish velocity, regional content volume) with compliance/incident tracking, compared against a matched sample of centralized proprietary CMS deployments. - H5: incident post-mortem analysis across a sample of enterprise WordPress security incidents, categorizing root cause as core-platform, plugin/ecosystem, hosting/config, or credential-related. ### ❓ Questions - What is the actual, sourced basis for the "43% of the internet" claim, and does it hold at the enterprise segment specifically (vs. all WordPress sites globally, which skews small-site-heavy)? - What real-dollar TCO data (not qualitative comparison) exists for enterprise WordPress vs. proprietary CMS at comparable scale — and does Human Made or a neutral third party publish it? - How does the "curate approved plugins" governance model scale in practice across an ecosystem with 60,000+ plugins of wildly variable code quality? - What does "governed at scale" for AI (Ch. 4.3) actually look like in a deployed enterprise instance — is there a reference implementation to audit? - What's the actual failure mode when the "Evolve" strategy goes wrong (technical debt accumulation, governance drift) — the document only describes Build/Buy failure modes. ### 🔮 Future Research - Independent (non-vendor) TCO benchmarking of enterprise WordPress vs. leading proprietary enterprise CMSs (Adobe Experience Manager, Sitecore, Contentful) at matched traffic/team-size tiers. - Longitudinal study of WordPress 7.0 AI Client adoption and its actual effect on editorial workflow speed and AI governance incident rates. - Comparative security incident analysis isolating core-WordPress vs. plugin-ecosystem vs. hosting-configuration root causes across enterprise deployments. ### 💡 Implications - **Practice:** Teams building a WordPress migration business case should treat this playbook as a structuring tool (the chapter framework is genuinely useful) but source their own TCO and security numbers rather than citing this document's unsupported comparisons. - **Policy:** The governance chapter's plugin-curation and pre-adoption review recommendations are adoptable as OSPO policy regardless of whether an organization ultimately chooses WordPress. - **Security:** Enterprise security reviews of WordPress should explicitly separate core-platform risk from plugin-ecosystem risk, since this document conflates them in WordPress's favor. - **Education:** The document assumes reader familiarity with terms like "headless," "composable," and "API-first" — useful as a glossary-adjacent primer for less technical stakeholders (CFOs, marketing leads) reading alongside a technical partner. - **Funding models:** The TCO argument (engineering investment vs. licensing fees) has real budget-allocation implications for how enterprise IT departments structure platform budgets between capex-like licensing and opex-like engineering headcount. ### 🧠 Learning Styles Assessment - Reading level estimate: approximately Flesch-Kincaid grade 9–10 (short sentences, low jargon density relative to enterprise technical content, frequent one-sentence paragraphs typical of marketing-deck-derived copy). #### 👀 Visual learners - Present: chapter-opening numbered sub-navigation, a labeled "three paths" comparison table (Ch. 7.1), a proprietary-vs-open comparison table (Ch. 5.3), a four-pattern architecture diagram set (Ch. 8.5). - Improve: the TCO chapter would benefit most from an actual cost-over-time line chart rather than prose comparison; the roadmap (Ch. 12.4) is a natural swimlane diagram candidate. #### 🔊 Aural learners - Present: none — no audio/podcast companion referenced. - Improve: a 3–5 minute narrated executive summary would suit the CFO/exec audience this document targets. #### 🗣️ Verbal learners - Present: consistent use of plain-language analogies ("shape the platform around the business, rather than adapting the business to the platform") and repeated definitional framing of composability/interoperability. - Improve: a glossary of the recurring technical terms (headless, composable, API-first, Multisite) would help non-technical stakeholder readers. #### 🧩 Kinesthetic learners - Present: the Ch. 12 adoption roadmap and "quick wins" checklist function as a lightweight action plan. - Improve: a self-assessment worksheet for Ch. 12.1's "platform maturity" questions would make this section usable in a live workshop. #### 🧠 Logical learners - Present: the Build/Buy/Evolve framework and the four architecture patterns (Ch. 8.5) are structured as clean decision categories. - Improve: the TCO argument needs an actual decision tree or cost model, not prose assertion, to satisfy logical-learner scrutiny. #### 🧑‍🤝‍🧑 Social learners - Present: stakeholder-alignment framing in Ch. 12.3 (technical, marketing, finance perspectives). - Improve: no discussion prompts or forum/community tie-in; this is a one-way document with no engagement mechanism. #### 🧘‍♀️ Solitary learners - Present: self-contained chapter structure lets a reader work through sections independently. - Improve: a self-assessment checklist per chapter (beyond Ch. 12.1) would support solo evaluation work. #### 🌿 Naturalistic learners - Present: none — no sustainability/environmental framing in the document. - Improve: hosting/infrastructure chapter (Ch. 10) could note energy/efficiency implications of autoscaling vs. over-provisioned proprietary infrastructure, which is a live enterprise procurement consideration. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: the source is a PDF whitepaper; original document structure (headings, chapter numbering) is visually clear but PDF heading semantics were not verifiable from the extracted text alone. - Improve: if republished as HTML/web content, ensure true semantic headings (not just large/bold text) and add alt text for the architecture-pattern and comparison-table graphics. #### Keyboard navigation - Present: N/A — static PDF document, no interactive elements to assess. - Improve: if converted to a web page, ensure the chapter table of contents is keyboard-navigable with visible focus states. #### Contrast and readability - Present: not assessable from extracted text; original PDF uses letter-spaced all-caps headers which can reduce screen-reader and low-vision readability if not paired with sufficient size/contrast. - Improve: avoid all-caps letter-spaced running headers as the primary heading style — they're a known low-vision/dyslexia readability issue regardless of color contrast. #### Text resizing and reflow - Present: N/A for a fixed-layout PDF. - Improve: an HTML companion version would support 200% zoom reflow, which a fixed A4 PDF layout cannot. #### Media and captions - Present: no audio/video in this document. - Improve: N/A. #### Forms and interactions - Present: several "Download the guide" CTAs function as simple links, not forms, in the extracted content. - Improve: if gated behind a form, ensure labeled fields and accessible error handling (not assessable from this extract). #### Standards reference - Ironically, the document itself claims WordPress "can support" WCAG-aligned accessibility (Ch. 6.3) while being distributed as a fixed-layout PDF, which is a common accessibility gap (WCAG 2.2 SC 1.4.4 Resize Text, 1.3.1 Info and Relationships) for exactly the kind of content it's describing. ### 🌍 DEIB Assessment #### Cultural breadth - Present: the "MENA & beyond" AGBI case study is the only geographically specific example; otherwise language is globally generic ("global publishers," "regions," "markets"). - Improve: additional region-specific case studies (APAC, LATAM) would strengthen the "global platform" claims beyond the single MENA example. #### Inclusive language - Present: consistently uses "organisations" and "teams" rather than gendered or role-biased language; British English spelling throughout ("organisation," "customisation," "localisation") is internally consistent. - Improve: none needed — language is already neutral and jargon is generally defined in context. #### Neurodiversity support - Present: consistent chunked structure (numbered chapters, sub-numbered sections, repeated "key takeaways" framing) supports predictable navigation. - Improve: the all-caps letter-spaced headers (noted above under Accessibility) work against neurodiversity-friendly reading; standard-case headers with clear hierarchy would help. #### Representation - Present: minimal — the document is largely abstracted to "organisations" and "teams" without named individuals, roles, or images described in the extracted text. - Improve: if human profiles/quotes exist in the original visual design, ensure varied representation in imagery and named case-study contributors. #### Psychological safety - Present: tone is consistently non-alarmist and solution-oriented, avoiding fear-based sales tactics. - Improve: N/A — no content warnings or moderated discussion needed for this document type. ### ✅ Logical Validity #### Strong reasoning - The TCO argument (Ch. 5.1–5.2) uses a coherent causal chain: proprietary licensing tiers → step-function cost increases → reduced ability to experiment → slower innovation. This is internally consistent and matches widely reported enterprise SaaS/CMS procurement patterns, even without this document's own supporting data. - The composable-architecture argument (Ch. 8) is a strong analogical/causal case: it correctly identifies that loosely coupled systems (via APIs/webhooks) reduce the blast radius of any single component's replacement — a well-established software architecture principle, not just marketing framing. #### Fallacies - **False trilemma / false dichotomy (Ch. 7.1):** "Build vs. Buy vs. Evolve" is presented as an exhaustive, objective framework, but "Evolve" is defined in terms that are functionally synonymous with "open-source/WordPress," making the comparison circular — the conclusion is embedded in the category definitions. Fix: present Evolve as a strategy orthogonal to platform choice (proprietary platforms can also be extended incrementally via APIs) rather than as WordPress's exclusive property. - **Appeal to popularity (Ch. 3.2):** "43% of the internet" is used to imply enterprise-readiness, but market-share-of-all-sites is a weak proxy for enterprise-grade capability (most WordPress sites are small/non-enterprise). Fix: cite enterprise-segment-specific adoption data if it exists, or drop the stat. - **Unfalsifiable/unsupported comparative claims (Ch. 5, throughout):** Statements like "open platforms allow these changes to be managed incrementally" vs. "proprietary platforms often introduce step changes in cost" are stated as general truths without a single dollar figure, case study, or citation across the entire TCO chapter. Fix: at minimum, cite one sourced case study with real numbers. #### Tone of voice - Confident, consultative, and calm throughout — avoids overt fear-mongering or urgency tactics ("act now," "your competitors are already..."). Tone is closer to a McKinsey-style advisory brief than a hard-sell datasheet, e.g., "There is no single blueprint. What matters is alignment between platform design and organisational needs" (Ch. 13.2) — a notably humble framing for a vendor document. ### 🛡️ DARVO Analysis - This document is not a rebuttal, defense, or response to an accusation, so classic DARVO dynamics (Deny/Attack/Reverse-victim-offender) don't structurally apply. - The closest analog is a mild "attack" pattern directed at an abstract, unnamed target: proprietary CMS platforms are repeatedly characterized as imposing "vendor lock-in," "externally influenced roadmaps," and "step changes in cost" — real and often valid criticisms, but never attributed to a specific named competitor or backed by a named incident, which keeps the framing rhetorically safe (no rebuttal is possible from an unnamed opponent). - No emotional-appeal or victim-framing rhetoric detected — the persuasive strategy relies on structural/cost argumentation rather than emotional appeals, consistent with the "Strong reasoning" notes above. ## 🎯 Conclusion - Human Made's core claim — that WordPress functions as a strategic, composable platform rather than a tactical CMS — is a reasonable and increasingly mainstream enterprise position, and the document's chapter framework (assess → architect → govern → scale → future-proof) is genuinely useful as a planning scaffold. - The weak point is evidentiary: the TCO chapter, which is the document's central and most consequential claim for a buying decision, contains no sourced numbers anywhere. Readers evaluating a real migration should use this playbook to structure their thinking, then independently source cost, security-incident, and adoption data before taking any comparative claim to a budget or board conversation. - Practical next step: treat Chapters 5 (TCO) and 6 (Governance/Security) as the two sections requiring outside verification before this document informs a procurement decision; the architecture (Ch. 8) and adoption-roadmap (Ch. 12) chapters are usable as-is for internal planning discussions. ## 🔄 Refactor Appendix — The Enterprise WordPress Playbook ### 📚 Literature Atoms (H3) #### Evolve strategy avoids full-platform replatforming cycles > [!quote] > "Instead of replacing everything at once, organisations build on a flexible foundation and improve it continuously." **Context & use**: - Chapter 7.1, "The Three Paths" — defines the Evolve path against Build and Buy. - Central to the document's core thesis; worth testing against real migration case data before reuse. **Tags**: #xref  #### Open platforms shift cost from licensing into engineering > [!quote] > "Open platforms like WordPress shift more of that investment into engineering." **Context & use**: - Chapter 5.1, "Breaking down true platform costs" — the document's central TCO claim, stated without supporting figures. - Flag for #articleseed: worth its own piece testing this claim against real procurement data. **Tags**: #articleseed  #### AI Client standardizes WordPress-to-AI-provider connections > [!quote] > "Now, with emerging core support for AI through the AI Client, it becomes much simpler to connect to different AI providers in a consistent way." **Context & use**: - Chapter 4.1, "Embedding AI into publishing workflows" — describes WordPress 7.0's AI Client. - Most independently verifiable technical claim in the source; cross-reference against WordPress core changelogs. **Tags**: #xref  ### 🧠 Permanent Candidates (H4) #### Build/Buy/Evolve framing collapses into a circular argument for open source **Claim** (one sentence, Courtney's voice): Any three-path platform framework that defines its preferred path in terms synonymous with the vendor's own product has already decided the outcome before the comparison starts. **Evidence pointer**: [[Literature note#Evolve strategy avoids full-platform replatforming cycles]] **Scope & conditions**: Holds for vendor-authored comparison frameworks generally, not just this document; breaks down if the framework's categories are defined independently of any single vendor's product (e.g., "incremental" vs. "big-bang" migration, decoupled from platform choice). **Links** (≥1 with annotation): - [[Vendor-content-evaluation]] — because applies-in reading any vendor whitepaper that proposes an N-path decision framework  ### ✏️ Fleeting Queue - [F1] Find a non-vendor TCO comparison of enterprise WordPress vs. AEM/Sitecore/Contentful to fact-check Ch. 5's core claim — #xref - [F2] Verify WordPress 7.0 AI Client scope/capabilities directly against core WP changelogs rather than this vendor's characterization — #xref ### → Things 3 (max 2 actions) - [ ] Look up an independent enterprise-WordPress-vs-proprietary TCO study — research #things --- Done — full deep-read note above, following the template's strict heading rules (Notes promoted to its own H2 per the override instruction) and stopping at the Things 3 section as instructed.