Kooboo CMS — Modernization Readiness Profile

Executive summary

Kooboo CMS is a large, .NET Framework multi-tenant content-management platform: 31 projects spanning a web front-end, core content and site-management libraries, a membership and account system, a forms engine, full-text search, pluggable caching, an extensive set of swappable storage backends, and three template engines running simultaneously. This is not a line-of-business application -- it is a platform built to be deployed in many configurations. The difficulty is not a lack of structure: the persistence layer is cleanly separated into provider projects and the DI container is isolated in its own module. It is the combination of total platform lock-in, the breadth of integrations, and an automated test suite entirely absent from the build.

The dominant risks are platform-bound and certain. Every project targets .NET Framework -- 30 on net40 and one (Kooboo.CMS.Content.Persistence.FileServerProvider) on net45 (RULE-001) -- and net40 has no incremental path to modern .NET. On top of that sits System.Web saturation across roughly 19 projects and hundreds of files (RULE-002): the web layer, all three template engines, the forms library, the caching infrastructure, the membership system, and the base utilities all depend on namespaces that do not exist in modern .NET, so this is a rewrite of the web surface, not a port.

The platform carries distinct integration risk: an internal WCF file-server service (RULE-029) and Windows COM interop in WebPageCapture_DefaultProvider.cs (RULE-031). Beneath the blockers it assumes single-process execution throughout -- 217 mutable-static-state findings across 24 projects (RULE-006) and in-memory caching and session everywhere (RULE-020) -- and its reference graph funnels through a few load-bearing projects (Kooboo.CMS.Web pulls in 9 sibling projects, Kooboo.CMS.Sites 8), so the pieces cannot be modernized in isolation.

What it can absorb today is essentially nothing without a platform decision first, and there is no safety net: zero test projects exist in the solution (RULE-012), which is maximum change-failure risk for a migration of this scale. This is a full re-platforming program, not an incremental modernization, and its largest questions are senior architect judgment the engine cannot make: which of the eight storage backends and three template engines survive, and what becomes of the WCF file server and the COM-based page-capture component.

Risk register — representative critical rows

Presented in the 12-field LMRR schema; only the representative columns are shown here, and the corrected false positives are excluded. Priority is the engine's severity score for each finding -- Probability (1–5) × Impact (1–5), so it runs 1–25 and a higher number is more severe; the rows below are all in the Critical band (Priority 20–25). Confidence and automation level are senior architect estimates; type-resolution-dependent findings carry the semantic caveat in Confidence & coverage.

Consolidation and blind spots. The three WCF surfaces are one underlying file-server integration -- service contracts (RULE-029, R-004), config endpoints (RULE-034, R-011), and the external-protocol view (RULE-033, R-013) -- kept separate for scoping but resolved together. The boilerplate [ComVisible] across all 31 AssemblyInfo.cs files is an engine-acknowledged false positive, de-weighted and not scored. And Category 6 (External Dependency Risk) produced no findings, which is a blind spot, not a clean bill of health. Every third-party dependency here is a committed raw DLL under /Lib -- an old Azure StorageClient, MySQL, MongoDB, Lucene.Net, an aging OAuth library, and more -- rather than a package reference the scanner can see, so a decade-old vendored supply chain reads as “none” to the package model. It is a manual diligence item, not an absence of risk.

Suggested modernization sequencing

1. Decide the platform and the architect-only questions. Choose the target framework (R-001), and make explicit calls on which of the eight storage backends and three template engines survive, on the WCF file server (R-004), and on the COM page-capture component (R-006). Everything downstream depends on these; they are Migration-Feasibility, Embedded-Business-Logic, and Domain-Knowledge work the engine cannot do.
2. Lay the safety net. Add a baseline test suite (R-003) and minimal structured logging and observability (RULE-028) before touching the high-risk paths -- a prerequisite, not a parallel task, especially over the god classes and the WCF/COM paths. Eight test projects exist on disk but are excluded from the build; they are the asset to resurrect first when deciding which backends survive.
3. Clear the contained hard blockers and externalize config. Resolve or replace the WCF file-server surface (R-004 with RULE-034 / RULE-033) and the COM page-capture component (R-006); externalize the hardcoded Kooboo_CMS connection strings (RULE-023), the hardcoded URLs (RULE-014, 19 instances), and the config-defined WCF endpoints (RULE-034).
4. Move the graph together, hub-first. Stabilize and retarget the shared hubs -- Kooboo.CMS.Common, Kooboo.CMS.Content, and the Kooboo base library -- as one coordinated unit (the RULE-018 fan-out makes piecemeal porting unsafe); rewrite the System.Web surface (RULE-002) onto ASP.NET Core, replace Forms auth and Membership (RULE-036) with a chosen identity stack, and migrate the four EF6 projects (RULE-022) to EF Core. Replace in-memory caching and session (RULE-020) with a distributed cache and triage the 217 mutable-static-state findings (RULE-006).
5. Close the engine's blind spots with senior architect review. Run a database-trigger inventory (Signal 5.2), confirm the schema-management approach for the EF projects (Signal 4.4), classify each AppDomain usage (Signal 1.4), inventory the vendored /Lib binary supply chain that Category 6 cannot see, and decide the deployment topology (Signal 7.2). These are categories and signals the engine explicitly cannot resolve alone.

What we corrected from the first run

This is the part most diagnostic tools never show you. Earlier engine runs produced findings a source read did not support; they were removed at the source before this profile, and the publication run is strictly cleaner for it -- the same discipline that makes the score worth trusting:

• An inflated body of “inline SQL.” An early RULE-008 count was padded by select / <select> text in prose and markup that the detector misread as SQL. Removed at the source (engine fix C1-022) and re-anchored to the genuine query-translator SQL in TranslatedMediaContentQuery.cs and TranslatedTextContentQuery.cs -- the real inline SQL that R-005 carries.
• A false class of “implicit schema dependencies.” RULE-010 matched Razor, JavaScript, regex, and comment text as schema-qualified database references. An adversarial scan of every flagged file found zero genuine schema references, so the count fell from 156 to 0 (engine fix C1-002). Nothing real was lost.
• Boilerplate COM visibility, de-weighted rather than scored. The [ComVisible] attribute is Visual Studio boilerplate present in all 31 AssemblyInfo.cs files; it is an acknowledged false positive, de-weighted and not counted as COM-interop risk. The genuine COM interop is a single file -- WebPageCapture_DefaultProvider.cs (R-006).

The platform read here -- net40 throughout, System.Web saturation, the WCF file server, COM interop, EF6, and no tests -- is source-verified and stands. The senior architect read against this exact publication run is a re-confirmed AGREE (the architect concurs with the engine's read).

Modernization lesson

Review all public codebase teardowns →