SilverStripe 4 reached end of support in April 2025. For New Zealand and Australian organizations that built government portals, university sites, and council websites on it, that deadline has passed, and SilverStripe 5 requires a developer rebuild that most teams with aging installs have not budgeted for.
A New Zealand CMS With a Loyal Government Following
Born in Wellington in 2000 and released publicly as open source around 2006, SilverStripe grew into the dominant CMS for New Zealand’s public sector. Government agencies, district councils, district health boards, universities, polytechnics, and crown entities built their digital presence on it. The platform genuinely earned that trust: the DataObject ORM, the staged draft-live publishing workflow, the fine-grained permission system, and the versioning model were real advantages for content-heavy public sector sites that needed editorial control.
The Common Web Platform (CWP) deepened the lock-in further. CWP was the New Zealand government’s shared hosting infrastructure for SilverStripe sites, providing managed hosting, security monitoring, and a common baseline of modules. By 2019, hundreds of NZ government sites were on CWP. The platform became infrastructure.
Then the EOL cycle began accumulating. SilverStripe 3 went end-of-life in September 2021. SilverStripe 4 entered security-only limited support in April 2024 and reached full end-of-life in April 2025. The Silverstripe Cloud Public Sector On-Prem (SCPS) hosting plans retired on 30 September 2025. Organizations that have not migrated off CWP since that date are operating without hosting support. And SilverStripe 6 was released in June 2025, meaning organizations on SilverStripe 4 are now two major versions behind the current supported release.
The Upgrade Pressure That Never Fully Resolves
The jump from SilverStripe 3 to SilverStripe 4 was the most disruptive upgrade the platform has seen. The architecture shifted from a monolithic application to a Composer-driven module system with PSR-4 autoloading. Custom templates, custom DataObjects, and custom modules all required updates to the new namespace conventions. Many agencies found the upgrade cost comparable to a site rebuild and treated the EOL deadline as a trigger to evaluate their platform choice rather than fund the upgrade.
SilverStripe 5, released in April 2023, was deliberately designed to minimize upgrade disruption from version 4. For organizations already on a well-maintained SilverStripe 4 install, the upgrade was manageable. But for the large number of SilverStripe 4 sites that accumulated technical debt through years of minimal maintenance, version 5 arrived simultaneously with the EOL deadline for version 4, compressing the decision window.
Many agencies are starting to drop support for SilverStripe. Silverstripe has a smaller but dedicated community here in New Zealand, but be careful.
Bronte, SilverStripe vs WordPress for NZ Businesses, September 2025
Smaller Developer Pool: finding experienced SilverStripe developers is harder, which can make long-term support more difficult and expensive. Limited Ecosystem: compared to WordPress’s 60,000+ plugins, SilverStripe’s module library is much smaller, meaning more features must be built from scratch.
Weave NZ, Why Use WordPress in 2025, August 2025
The Module Ecosystem Gap
SilverStripe has around 2,000 modules in its ecosystem. WordPress has over 60,000 plugins in the official repository, with tens of thousands more in commercial marketplaces. That ratio matters at every stage of a project. When a client wants a new feature, a WordPress developer can almost always find a maintained plugin that does it. When a SilverStripe developer needs the equivalent, they often need to build it from scratch or find a module that is two major versions behind and has not been updated since 2021.
The unavailability of many pre-made plugins means a complicated project can depend on hard-coding and dev time which may not be ideal or affordable for clients.
Verified reviewer, Capterra NZ, SilverStripe CMS
I worry about the scalability of this due to not as many plugins being available as WordPress. WordPress will remain my choice for larger projects.
Verified reviewer, GetApp NZ, SilverStripe CMS, 2025
SilverStripe Modules and Their WordPress Equivalents
Every piece of functionality in SilverStripe beyond basic page management is delivered through modules installed via Composer. Unlike WordPress plugins which install through the admin UI, SilverStripe modules require developer involvement to install, configure, and upgrade. And each major version of SilverStripe may require a module update that the original author has not yet shipped. The table below maps the most commonly used SilverStripe modules and core features to their WordPress equivalents.
| SilverStripe Module / Feature | What It Does | WordPress Equivalent | Cost |
|---|---|---|---|
| Pages / SiteTree | All site pages with draft/live versioning and tree hierarchy | WordPress Pages (built in) | Built in |
| Custom Page Types (DataObjects) | PHP classes extending SiteTree with custom fields | Custom Post Types + ACF Pro custom fields | Free + Pro |
| Elemental Blocks (dnadesign) | Block-based page builder: text, image, gallery, video blocks | Gutenberg Block Editor + ACF Blocks | Free + Pro |
| User Defined Forms (UDF) | Drag-and-drop form builder with email notifications and submissions | Gravity Forms / WPForms / Fluent Forms | Free tiers |
| Blog module | Blog posts with categories, tags, and archives | WordPress native blogging (built in) | Built in |
| Members + Groups | Front-end registration, profiles, and group-based access | WordPress User Roles + MemberPress | Free core |
| Assets / File system | Versioned file and folder management with access control | WordPress Media Library (built in) | Built in |
| SiteConfig | Site-wide settings editable in the CMS | ACF Options Pages + WP Customizer | Free + Pro |
| Fluent (multilingual) | Multi-language content with locale-based routing | WPML / Polylang | Free + Pro |
| Comments | Threaded user comments on pages and blog posts | WordPress native comments + wpForo 360° AI | Free + Pro |
| GridField lists | Sortable list management for related DataObjects in the CMS | WP Admin + ACF Relationship / Repeater | Free + Pro |
| Versioning (Versioned) | Draft, published, and archived content states per item | WP PublishPress Revisions / core revisions | Free core |
| SS Templates (.ss) | SilverStripe-specific template engine for all front-end output | Custom WordPress PHP theme | Custom dev |
For organizations that want to add a full community discussion platform to their new WordPress site, gConverter implements wpForo 360° AI as part of the migration. Whether the SilverStripe site used the core Comments module, a custom DataObject-based discussion system, or no forum, wpForo 360° AI delivers forum categories, topic subscriptions, member ranks, and AI-powered moderation that SilverStripe Comments never supported.
What a Proper SilverStripe Migration Involves
SilverStripe stores its content in MySQL using an ORM-driven schema where each PHP DataObject class generates its own database table. This means the content is spread across dozens of tables named after your custom page types. A proper migration reads the source database directly and maps each layer explicitly.
Pages and the SiteTree
All pages in SilverStripe are stored in the SiteTree table (draft) and SiteTree_Live table (published). Each custom page type (PHP class extending SiteTree) also has its own table with the same name as the class, holding the custom fields defined on that page type. For example, a NewsPage class would have a SiteTree row for core fields and a NewsPage row for its custom fields, joined by the same ID. A proper migration reads both, maps all fields to their ACF Pro counterparts in WordPress, and creates the page tree hierarchy as WordPress page parents and post archives. The URLSegment field in SiteTree is used to preserve or redirect every existing URL.
Elemental blocks to Gutenberg
Sites using the Elemental block package store page content in ElementalArea and individual block tables: BaseElement (shared fields) plus per-type tables like ElementContent, ElementImage, ElementFile, and any custom blocks the site defined. A proper migration reads each block type, maps it to the equivalent Gutenberg block in WordPress, and reconstructs the visual layout of every Elemental-based page block by block.
User Defined Forms and submissions
The UDF module stores form field definitions in EditableFormField and every submission in SubmittedForm and SubmittedFormField. This is where citizen enquiries, grant applications, event registrations, and contact requests accumulate for government and public sector sites. Every submission including all field values is exported and archived during migration. No inquiry record is lost.
Members and groups
SilverStripe Members are stored in the Member table: email address, first name, surname, hashed password, and registration date. Group assignments are in Group_Members. Custom profile fields on the Member DataObject are in a separate Member subclass table. All registered Members are imported to WordPress with role mapping. Custom Member profile fields are imported as WordPress user meta.
Assets and files
SilverStripe asset records are in the File and Folder tables. Physical files are in the assets/ directory with a protected subfolder structure for draft files. A proper migration reads the File table, imports all assets to the WordPress Media Library preserving filenames and folder paths, and updates all content references to point to the new WordPress media URLs.
Templates to WordPress theme
SilverStripe uses its own template engine with `.ss` template files containing a mix of HTML and SilverStripe-specific syntax like $Title, <% loop $Children %>, and <% include SideBar %>. These templates cannot be ported to WordPress. A proper migration delivers a custom WordPress theme that replicates the visual output of the original SilverStripe site exactly: every layout, every content type view, every navigation structure, and every responsive breakpoint. The result is visually identical to the original with no dependency on the SilverStripe template engine.
What Bad SilverStripe Migrations Look Like
- Custom page type fields silently lost. Generic tools do not know about the separate table per DataObject class. They read
SiteTreefor core fields and miss every custom field table. Dates, images, related content, and all structured custom data disappears. - Elemental blocks flattened. Pages built with Elemental blocks have their content spread across multiple block tables. Generic tools scrape the rendered HTML output and produce a single flat content block. All block structure and any block-specific custom fields are lost.
- UDF submissions abandoned. The
SubmittedFormFielddata is in UDF-specific tables that no standard WordPress importer handles. Years of form submissions from government portals and council websites disappear. - URL structure not preserved. SilverStripe URLSegments define the URL for every page. Generic tools create default WordPress slugs with no connection to the original URLs and implement no redirects. All inbound links and search engine rankings break immediately.
- Draft versions published incorrectly. SilverStripe maintains separate draft (
SiteTree) and live (SiteTree_Live) versions. Generic tools may import from the draft tables, publishing unfinished content. - Templates not rebuilt. Some providers copy the rendered HTML of pages into a generic WordPress theme. The result fails immediately when content is edited and has no maintainable template structure.
Privacy Act and Your Data
A SilverStripe database built for a New Zealand government agency or council contains personal data governed by the Privacy Act 2020. For Australian organizations, the Privacy Act 1988 and Australian Privacy Principles apply. For UK and European organizations running SilverStripe, EU GDPR or UK GDPR applies. SilverStripe UDF submissions in particular may contain citizen service requests, grant applications, or event registrations with names, addresses, contact details, and other personally identifiable information collected over years of operation.
Migrating this to WordPress is a personal data transfer that requires a signed Data Processing Agreement before any provider accesses your database. gConverter is US-registered with EU GDPR compliance and documented processes compatible with the NZ Privacy Act 2020 and AU Privacy Act 1988. We sign a DPA before any access, store credentials in AES-256 encrypted vaults, transfer over TLS 1.3, and permanently delete all customer data within 30 days. Read the full GDPR and Data Protection documentation →
What Clients Say
Went FAR above and beyond to help us work through this project. We are thrilled with the final result and they were professional, great to work with, and responsive every step of the way. Would highly recommend.
Anna P., Wilmington NC – Customer Lobby, January 2026
Very few conversion issues on the first pass, and they cleaned it right. Very Impressive.
Stacy C., Katy TX – Customer Lobby, November 2025
The Bottom Line
SilverStripe earned its place in New Zealand and Australian government infrastructure through real technical strengths: clean ORM, staged publishing, fine-grained permissions, and a security posture that public sector procurement requirements respected. But SilverStripe 4 EOL in April 2025 and the CWP hosting shutdown in September 2025 have closed the “wait and maintain” option for a large number of organizations. The choice is now between funding a developer rebuild on SilverStripe 5 or 6, or migrating to a platform with a deeper ecosystem and a wider talent pool.
WordPress is where the module ecosystem is active, where the developer pool is global, and where a content team can publish and update without raising a developer ticket for routine work. Every SilverStripe page, every custom field value, every Elemental block layout, every UDF submission, every file, and every Member account can be migrated cleanly.