How Stack9 Gets Delivered, Start to Finish
April9 is both the platform owner and the implementation partner — one team accountable for migration, configuration, integration, training and support, with no vendor-versus-implementer handoffs. A hybrid methodology pairs waterfall rigour on what gets built with iterative delivery on how.
One Team, No Handoffs
April9 owns Stack9 and delivers it — the same organisation builds the platform, migrates your content, configures your workflows and supports the result. There is no separate implementation partner to coordinate, blame or wait on.
Every major digital experience platform is delivered through a partner channel — a vendor who builds the product, and a separate implementation partner engaged to build with it. When something breaks, the two sides can each point at the other. April9 cannot do that: the people who wrote Stack9’s code are the same people who configure your instance, build your integrations and pick up your support tickets. Delivery follows a hybrid methodology — waterfall discipline settles what gets built, through a signed-off Business Requirements Document and Technical Solution Design, before anything is built; execution is then iterative, delivered as a sequence of releases, each specified, built, tested, accepted and deployed through five governance gates.
“One point of accountability across platform, implementation, migration, training and support — no handoffs, and Level 3 support reaches the engineers who wrote the code.”
The same single-vendor position extends to how an engagement ends — see Continuity & Exit.
Five Gates, Every Release
Where AI is in scope, the evaluation set and pass threshold are approved before the first agent is configured — the same evaluation-as-release-gate discipline described in AI Governance.
Business Case Gate
A proposal validated against scope and estimated effort, confirming the change is justified before detailed work begins.
Requirements Gate
Feature Specifications extracted from the baselined Business Requirements Document, each carrying testable acceptance criteria traced to the requirement it satisfies.
Internal QA Gate
AI-generated UI and API test cases validate functional completeness; an AI evaluation run below the agreed threshold returns to development.
UAT Gate
Human testers in persona execute test cases in the April9 Deliver App, recording formal, auditable acceptance before release.
Release Gate
Once every UAT case passes, the release is scheduled and deployed under an approved Request for Change.
Five Testing Layers, Each With a Gate
Unit Testing
Developer-written tests run in the build pipeline on every commit, with coverage thresholds enforced.
System & Functional
Manual test cases plus AI-generated UI and API tests, tracked in the Deliver Portal and built into a growing regression suite.
Integration Testing
Contract tests per interface cover negative paths too — timeouts, throttling, retries and failover to manual review.
UAT
Human testers in the relevant persona sign off directly in the Deliver Portal, before any release is scheduled.
AI Validation
Per-answer scoring against approved datasets, plus full synthetic conversations judged against the intended outcome, on every change.
Two Reference Plans
Pick the plan that matches the engagement shape — migrating an existing estate, or building something new.
Portal Migration
- MVP-first: one mid-sized, content-driven portal proves the platform before the wider estate migrates.
- Coexistence: legacy and Stack9 portals run side by side — nothing forces a single cutover.
- Content is migrated page by page, verified with a pixel-comparison audit against the source site.
- ~6 months for the first portal end-to-end; each subsequent portal an estimated 8–16 weeks, depending on content and integration complexity.
Greenfield Build
- A new application — back office and web portal — with AI agents in scope from day one.
- The AI evaluation set and pass threshold are approved before the first agent is configured.
- A dedicated assurance phase — performance, accessibility and security testing — lands before UAT, not compressed into the build tail.
- ~8 months indicative from one scoping, assuming no bulk data migration; legacy data is a separately scoped package.
AI Accelerates the Rebuild, People Validate It
Migrating from a legacy CMS or DXP, not just Sitecore specifically. Discovery runs against static source code and configuration — never against your live, running application.
AI-Generated Requirements
AI agents analyse legacy source code and configuration into a structured Business Requirements Document — reviewed and validated jointly before it drives any migration decision.
Automated Content Migration
Pages are mapped and migrated automatically, then checked page by page with a pixel-by-pixel comparison audit against the source site before go-live.
Module Translation, Human-Reviewed
AI translates custom module logic into a structured starting point for developers — never automated migration of business logic — and every module is reviewed before use.
Training Runs Before Go-Live, on Purpose
Surfacing usability issues and knowledge gaps while there is still time to adjust, rather than discovering them once the portal is live.
Role-Based Training
Self-paced videos and how-to guides for content editors; live workshops for power users, business users and AI Agent configurators.
One Living Knowledge Base
Training, manuals and solution documentation live in a co-authored knowledge base — BookStack, a supporting documentation app provisioned with your solution — kept current on every release.
Key Users Build With Us
Nominated client staff configure functionality alongside April9 during the build, so capability transfers before UAT, not after go-live.
Ready to See How Delivery Actually Works?
Talk to us about your migration or greenfield build, or read what the Base Support Package commits to once you're live.