Migrate from Adobe Experience Manager to Strapi: what the move involves
A team that mainly uses AEM content fragments for headless delivery can move its content and assets to Strapi, but the frontend, page authoring and integrations are separate projects with their own owners and timelines. Content is the portable part; the delivery layer is a rebuild. Core support for on-premise AEM 6.5 ends on February 28, 2027, so the content export is usually the first workstream to start, while the frontend and integration decisions can run in parallel. The work is usually done by an internal platform team and a frontend team, with an implementation partner for the export tooling, the schema mapping and the Strapi hardening. On the content side, the export starts with Package Manager, which produces Jackrabbit FileVault packages that must be parsed before they can be loaded into Strapi. Each fragment model becomes a Strapi content type, and fragment references, localized variants and DAM asset links need explicit mapping rules that someone must write and test. Plan for the model mapping to take more review cycles than the data load itself.
Strapi 5 uses the Document Service API and a different response format from Strapi 4, so any Strapi 4 code a team has already written must be checked before it is reused. The self-hosted stack also needs PostgreSQL 14 or later, MySQL 8.0 or later, MariaDB 10.3 or later or SQLite 3, and a Node.js version on Strapi's supported list, because Strapi 5 does not support MongoDB. Confirm these requirements, your database backup procedure and your edition needs against the current installation docs before you commit to a schedule. The items most often underestimated are the frontend rebuild, the URL redirect map from the old AEM site structure, and the integrations with marketing and search tools. Build the redirect map from the live URL inventory rather than from the content model, and ask any implementation partner to show how it will be tested. Ask for a written scope that names each of these workstreams, the owner of each, and the acceptance tests that end the project.
Which AEM capabilities map cleanly to Strapi and which need rework
This table compares the main AEM capabilities against Strapi's content types, media library, APIs, Users and Permissions plugin and edition features. Read clean as a direct mapping, needs rework as a rebuild with known effort, and gap as something a Strapi-only stack does not provide. Page authoring and AEM Forms are gaps, so plan for separate tools or a rebuilt frontend for those.
| AEM capability | Strapi equivalent and fit | Result |
|---|---|---|
| Content fragment models | Content types with fields, components and relations in Strapi's content-type builder. Field types must be mapped by hand from AEM model definitions. | Needs rework |
| DAM assets | Media library holds files and metadata, but AEM asset renditions, folder taxonomy and processing profiles must be rebuilt or handled by a separate service. | Needs rework |
| Headless delivery APIs | REST and GraphQL APIs cover delivery of content types. Consuming applications must be rewritten to the new response format, and Strapi 5 changes it from v4. | Needs rework |
| Users and roles for editors | Admin users and roles cover editor access. Administrator login can use SSO, but end-user authentication sits in the Users and Permissions plugin. | Needs rework |
| Editorial workflows | Review workflows are an Enterprise feature in Strapi's self-hosted plans. Simpler approval steps may need custom build or a separate tool. | Needs rework |
| Multi-site and localization | Strapi supports locales on content types, but site structure, shared components and per-site permissions must be designed and built. | Needs rework |
| Page editing and visual authoring | Strapi has no page editor. Page layouts, drag-and-drop components and in-context preview must come from the frontend or another tool. | Gap |
| AEM Forms | Strapi does not provide adaptive forms, form workflows or document generation. Use a separate forms product or a self-hosted form builder. | Gap |
| Export of AEM content | Package Manager exports produce FileVault packages that must be parsed into Strapi entries and media uploads with scripts. | Needs rework |
What moves cleanly from AEM and what does not
Content fragments are the part of an AEM estate that moves most predictably, but nothing carries over automatically. Each fragment model has to be redeclared as a Strapi content type with explicit fields, relations and components, so start by inventorying every fragment model and the fields live pages depend on. The database decision comes first: Strapi 5 runs on PostgreSQL 14 or later, MySQL 8.0 or later, MariaDB 10.3 or later or SQLite 3, and does not support MongoDB or other NoSQL databases. Confirm your target database and Node.js version against the Strapi installation requirements before you write any mapping code.
AEM's documented export path is Package Manager, which produces Jackrabbit FileVault packages. These are zip archives scoped by filters that you define, and their content is XML descriptors alongside binary files, not a neutral JSON dump. Your team, or your implementation partner, will need a parser that reads the content XML, resolves node paths and references between fragments, and pulls the matching binaries from the DAM. Confirm which filters cover content fragments and which cover assets, and confirm that previous versions are not included in the packages, so you can decide now whether any revision history must be preserved some other way.
Page components, Sling models, AEM workflows and Experience Fragments do not move as data. Sling models are Java logic bound to AEM components, so their output must be rebuilt in the new frontend, and any business rules they contain need an explicit home in Strapi or the frontend. AEM workflows need replacement with a deliberate approval design. Strapi's review workflows are an Enterprise feature in its self-hosted plans, so check whether your approval process needs them or can run on simpler publishing rules. Experience Fragments are reusable page composites, so decide which ones become Strapi components or dynamic zones and which become frontend partials.
What data and integrations need to move, and how
Five workstreams make up an AEM to Strapi move: content fragments, DAM assets, accounts, URLs and integrations. Each needs a different tool and a different owner, and only some have a documented starting point. Map all five before you pick a migration date, because a gap in any one of them can block launch.
Content fragments into Strapi entries
Export the fragment paths with Package Manager as FileVault packages, then parse the XML into JSON. Map each fragment model to a Strapi content type, and use components for repeated or nested structures. No documented automated path exists from FileVault packages to Strapi entries, so plan for a custom parser. Test it on a copy of a few representative fragments, and check that references between fragments resolve to the right Strapi relations.
DAM assets and metadata
Copy original asset binaries separately from the content packages. Load them into the Strapi media library or an S3-compatible object store, and map AEM tags, alt text, titles and rights fields onto Strapi custom fields. Confirm which renditions and versions the new frontend needs, because the export carries only what you scope. Check that each asset path stays stable so that references in migrated entries still resolve.
Administrator and end-user accounts
Administrator access to the Strapi admin panel can use SSO with an identity provider such as Microsoft Azure Active Directory, including auto-registration and a default role. SSO is an add-on on the Growth plan and included in Enterprise, so confirm the plan first. End users are handled separately by the Users and Permissions plugin, and password hashes from AEM are unlikely to transfer, so plan a reset or a custom import for customer accounts.
URL and redirect maps
Export every published AEM page path and build a table that maps each old path to its new route in the separate frontend. Keep the mapping in version control, and add redirects in the frontend or at the edge so that search rankings and inbound links survive the cutover. No documented tool maps AEM page trees to new routes, so this is a manual or scripted task. Review high-traffic and externally linked paths first.
Translation, search and marketing integrations
Inventory every AEM connector that reads or writes content, including translation vendors, search indexes, analytics tags, form handlers and marketing platforms. For each one, decide whether it will call the Strapi REST or GraphQL API, receive Strapi webhooks, or be replaced. Reconnect and test them in a staging environment before cutover. Confirm each vendor's supported integration method, because most AEM connectors will not work with Strapi unchanged.
Migration sequence from inventory to decommission
This sequence moves AEM content fragments and assets into Strapi in controlled stages, so each phase produces evidence that the next one can rely on before AEM is switched off.
Inventory fragment models, assets and URLs
Your content architecture team lists every AEM content fragment model, its fields and variations, the DAM folder structure with asset counts and renditions, and the URL structure of each live site section. Pull the page inventory from the AEM Sites tree and the top traffic paths from your analytics. The output is a field mapping sheet that lists each AEM field, its proposed Strapi content type and component, and the owner who signed off on it. The step is done when every fragment model and site section appears in the sheet with an owner.
Pilot one fragment model and one site section
Choose one fragment model with a moderate number of entries and one site section, then export them from AEM with Package Manager using filters scoped to those paths. Parse the packages, load the content into a Strapi 5 instance you run in your own environment, and render the section through the separate frontend. Your developers and editors check that fields, relations, localized variants and assets display correctly. The output is a validated pilot dataset with a short defect log, and the step closes when editors sign off that the pilot content matches AEM.
Run the full migration in parallel
Run the remaining exports and imports while AEM stays authoritative for editing. Strapi receives content on a repeatable schedule, and your team reruns the load scripts until the output is stable. Compare entry counts, field values, asset checksums and published states between the two systems for every model. The output is a reconciliation report listing each mismatch and its resolution. Editors should not edit in Strapi during this phase, because the parallel copy is a test of the pipeline, not a second source of truth.
Test redirects and cut over
Load the redirect map built from the URL inventory into the frontend or your edge layer, then test every mapped old path against its expected new target and status code. Schedule a frozen content window in which editors stop publishing in AEM, run a final incremental export, and confirm the reconciliation report is clean. Then switch DNS or the frontend deployment to the Strapi-backed site. The outputs are a redirect test result showing expected and actual responses and a cutover record with the time the freeze began and ended, which your change board approves before the switch.
Monitor and hold AEM for the retention period
After cutover, watch error rates, broken links, search indexing and editor activity on the new stack. Keep AEM in a read-only state and retain its exported packages and asset archive for the retention period your legal, records and compliance owners agree in writing. Confirm the retention period with them before you start, because it is set by your obligations, not by this migration. The output is a post-cutover health report and a signed retention schedule.
Decommission AEM and archive evidence
When the retention period ends and the health report stays clean, shut down AEM instances, revoke service accounts and remove the Adobe licence or subscription at the renewal date your contract allows. Archive the field mapping sheet, reconciliation reports, redirect test results and the cutover record in your records system. The step is done when the decommission checklist is signed and the archive location is recorded for auditors who may ask how the content was moved.
Choosing the Strapi version and database before you import
Start by fixing the Strapi version, because it decides everything downstream. Strapi v4 reached end of life on April 30, 2026, and its final release, 4.26.2, will receive no further updates, so a new AEM migration should target Strapi 5 from day one rather than planning a v4 build that would need upgrading later. Strapi 5 also replaces the Entity Service API with the Document Service API and changes the response format, so your frontend developers should code against the v5 response shape and not the v4 one. The Strapi-Response-Format: v4 header exists for backward compatibility during a transition, but it is a bridge, not a target.
Next, choose the database from the supported list. Strapi 5 supports PostgreSQL 14 or later, MySQL 8.0 or later, MariaDB 10.3 or later and SQLite 3, and it does not support MongoDB or other NoSQL databases. For a content estate that will be imported from AEM, PostgreSQL is the usual choice for a production environment, but the decision belongs to your platform team, who should also confirm backup and restore procedures for whichever engine you pick. Strapi also runs only on Active or Maintenance LTS Node.js versions, so pin the Node.js version in your build image and check it against the installation documentation before the import rehearsal starts.
Plan for a patch routine from the first sprint. Strapi 5 minor releases have shipped roughly weekly, with v5.57.0 on October 7, 2026 and v5.58.0 on October 14, 2026, so an unpatched instance falls behind quickly. Assign an owner for reviewing the GitHub release notes, testing upgrades in a staging copy of the database and scheduling production patches. Before the project starts, confirm the current supported version, database versions and Node.js LTS status against the Strapi installation requirements, because these values change over time and the figures in this section will age.
How the migration differs by estate size and starting point
A single headless site that uses AEM content fragments for a modest set of content types is the simplest migration pattern. The content model is small enough that one team can map every fragment model to a Strapi content type in a few working sessions, and the export usually covers one repository path with a bounded set of DAM folders. The main effort sits in the frontend, because the site has to be rebuilt to call Strapi's REST or GraphQL API instead of AEM's delivery endpoints.
- Export scope: One content path and one DAM folder tree, scoped with Package Manager filters, is often enough to cover the full content set.
- Integrations: Usually a small number, such as search, analytics and a deployment pipeline, so you can list each one and confirm its replacement early.
- Frontend rebuild: The site's components are the largest share of the work, and the rebuilt frontend is deployed separately from Strapi.
- Strapi edition: The Community Edition may cover the need, but you should confirm whether administrator login needs SSO, since that is an add-on on the Growth plan and included in Enterprise.
Before you start, confirm with your team which fragment fields carry rich text or references, because those are the fields most likely to need manual rework during mapping.
A multi-brand estate with many fragment models, several locales and shared asset libraries takes longer because every brand can have its own variations of the same model. The mapping work multiplies, and you need to decide early whether brands share Strapi content types with a brand field or keep separate models. Locale handling and fallback rules become a design decision rather than a copy task, and the number of consuming frontends usually grows with the brand count.
- Export scope: Several repository paths, many DAM folders and locale-specific fragments must be exported and reconciled, which needs an inventory before any export runs.
- Integrations: Each brand often connects to its own analytics, commerce or search service, so the integration list is longer and needs an owner per brand.
- Frontend rebuild: Shared component libraries reduce duplicate work, but each brand's templates still need to be tested against the new API responses.
- Strapi edition: Confirm which administrators need SSO to the admin panel, and whether audit logs or review workflows, which are Enterprise features, are needed for brand approval chains.
Ask your team to produce a fragment model inventory per brand and per locale, because that inventory determines how many Strapi content types and components you will build.
Some teams use AEM for page authoring with templates, editable components and the page editor, not only for headless fragments. Strapi does not provide a page editor for composing layouts, so the migration changes who builds pages and how. Content may move into Strapi as structured entries, while page composition moves into the frontend or a separate tool, and editors need training on a different workflow.
- Export scope: Page trees and their component properties are not the same as fragments, so the export must be checked against what each page actually stores.
- Integrations: Page-level personalization, forms and workflow tools may need their own replacement plan, since they often depend on AEM services.
- Frontend rebuild: Templates and layout logic move into code, so frontend developers take on work that editors previously did in the page editor.
- Strapi edition: Ask whether the editorial team needs content history, releases or review workflows, which start at the Growth plan or are Enterprise features, before you choose a plan.
Before committing, confirm with editors which pages they change most often, because those pages determine whether a structured-entry model will work or whether a separate page-building layer is needed.
What drives cost and duration in an AEM to Strapi move
This table lists the drivers that most change the effort of moving AEM content fragments and assets into Strapi, with how each one changes the work and how to keep it contained. Read it alongside your inventory, because most of the cost sits in the content model and the frontend rebuild rather than in the software licence. The main takeaway is that a Strapi move is priced by the size and quality of what you migrate, not by the platform.
| Driver | Why it matters | How to reduce it |
|---|---|---|
| Fragment models and nested references | Each AEM content fragment model becomes a Strapi content type, and nested references add relations, components and population logic that must be tested. | Consolidate overlapping models before mapping, and document every reference path in the inventory. |
| Asset volume and metadata quality | Assets move as files plus metadata, so large libraries and inconsistent tags extend export, transfer and validation time. | Remove unused renditions and orphaned assets, and agree a metadata schema before the bulk transfer. |
| Number of locales | Each locale multiplies entries, translation links and fallback rules, and Strapi's locale handling must match AEM's language copies. | Confirm which locales are live, retire inactive ones, and map fallback behavior with the content owners. |
| Custom Sling models and workflows | Custom Java logic that shapes content or drives approvals has no direct Strapi equivalent and must be rewritten as Node.js services or lifecycle hooks. | List every custom model and workflow, then decide which ones are still needed before writing any code. |
| URL count and redirect rules | Each published path needs a mapped destination, and pattern rules for dynamic pages add test cases and risk to search rankings. | Export the full URL list from your analytics and crawl data, and keep redirect rules in a version-controlled file. |
| Frontend rebuild scope | Strapi serves content only, so templates, components and page rendering are built as a separate application, often the largest single effort. | Reuse existing design tokens and component structure, and limit the first release to the highest-traffic templates. |
| Integrations | Connections to commerce, search, forms, analytics and identity each need a replacement or an adapter, and each adds testing. | Rank integrations by business value, then retire or defer the ones that no longer serve a live need. |
| Team skills in Node.js and TypeScript | Strapi customization and the frontend are written in JavaScript or TypeScript, so teams without these skills need training or outside help. | Confirm the skills gap early, and ask any partner to name the engineers and their experience in writing. |
| Hosting, Strapi plan and upgrades (recurring) | Hosting, database and backups recur monthly, a paid Strapi plan adds per-seat or per-project fees, and Strapi 5 releases ship often, so upgrades are ongoing work. | Compare self-hosted Community with the Growth or Enterprise features you actually need, and budget a regular upgrade cycle. |
| Inventory, mapping, scripts, build and testing (one-time) | Inventory, schema mapping, migration scripts, frontend build and test cycles are one-time costs that scale with the drivers above. | Ask for each phase as a separate line in the written scope, with a named deliverable and acceptance criteria. |
What usually goes wrong and how to prevent it
Most failed AEM-to-Strapi moves fail on assumptions made early: that exports are clean, that the frontend is a small task, and that URLs and rights will sort themselves out. Each card below names one risk, why it matters for this move, and the check to run before cutover.
Treating fragment exports as a clean import
Package Manager output is a set of FileVault packages scoped by filters, not a ready-made content model. Content fragments reference models, tags, and DAM paths that have no Strapi equivalent until you map them. Parse the packages, count fragments per model, and load a sample into a staging Strapi instance before you commit to a full run. Confirm which fragment variations and localized versions your filters actually captured.
Underestimating the frontend rebuild
Strapi delivers content through REST and GraphQL, so AEM's page rendering, component includes, and Sites templates must be rebuilt in a separate frontend. This work is usually larger than the content move and needs its own scope, owner, and test plan. Ask your team to inventory every AEM component and template that editors rely on, then decide which ones become Strapi content types and which become frontend code.
Losing URL structure and SEO equity
AEM page paths often follow a content tree that does not match the URL structure you want in a headless frontend. Without a redirect map, search rankings, inbound links, and bookmarks break at cutover. Export the live URL list from analytics and server logs, map each old path to a new route, and load those redirects before DNS changes. Keep the map under version control so it can be audited later.
Asset metadata and rights gaps
DAM assets carry renditions, tags, expiry dates, and usage restrictions that a plain file copy drops. Strapi's media library stores files and basic fields, so rights information must be carried into custom fields or a separate register. Before migration, ask legal and brand teams which assets have licence limits, and verify that each record in Strapi still shows its source, owner, and expiry date.
Upgrading or downgrading Strapi incorrectly
If you use Strapi v4 as a starting point, note that v4 reached end of life on April 30, 2026, so new work should start on v5. The upgrade path uses codemods and a data migration on first start, and the docs say downgrading is not supported. Back up the database before any upgrade step, test the migration on a copy, and keep the backup until the new version has run in production for a full cycle.
Running out of AEM support time
Core support for on-premise AEM 6.5 ends February 28, 2027, and extended support with critical fixes only runs until February 28, 2028. Migration projects often slip because export, mapping, and frontend work each take longer than planned. Set a dated cutover plan that works backward from the core support date, agree on a go or no-go checkpoint, and confirm with Adobe which support option applies to your contract.
Running AEM and Strapi in parallel and cutting over
Keep AEM authoritative until the Strapi copy has passed every reconciliation check. During the parallel run, AEM stays the system of record for editors, and Strapi receives only scripted loads from the export packages. Point the new frontend at a Strapi staging instance behind a feature flag or environment variable, so the old site keeps serving production traffic. Decide in advance who signs off each stage, and record that decision in the migration runbook rather than in chat threads.
Reconcile counts and checksums per content type, not just in total. For each fragment model, compare the number of AEM content fragments with the number of Strapi entries in each locale and state, including drafts and unpublished items if you migrate them. For assets, compare the file count and a SHA-256 checksum of every binary in the DAM export against the files stored in your object store, and treat any mismatch as a blocking defect. Schedule a content freeze with the editorial lead for the cutover window, disable publishing in AEM for the affected trees, and confirm with the business owner how long that freeze can run. Those durations are organizational decisions, not values this page can supply.
Write down what happens to content edited during the parallel run before the first load. Choose one rule: either editors re-key changes by hand after the freeze, or you re-run the delta export for items modified since the baseline, with the risk that Strapi entries get overwritten. Test the delta script on a copy first. For rollback, keep the AEM publish environment and the DNS or CDN origin setting that points to it unchanged until the new site has been stable for an agreed period. If the cutover fails, switch the frontend data source back to AEM, reopen publishing, and preserve Strapi data for analysis. Confirm with Strapi's documentation that your version's database backup and restore steps are tested before the window opens.
Questions buyers ask before moving from AEM to Strapi
How much effort does moving from AEM to Strapi take?
The effort depends mostly on how much of the AEM estate is content fragments and assets versus page components, templates and workflows, because only the first two map cleanly to Strapi content types and the media library. Effort rises with the number of fragment models, the number of locales, the volume of assets with inconsistent metadata, and the amount of editorial workflow that must be rebuilt. Strapi 5 itself is a new platform for most AEM teams, so the schema design, the Document Service API usage and the separate frontend build are all new work. Ask any provider for a written breakdown of these components in the quote, and ask which parts are priced per model, per asset set and per redirect rule.
How long does an AEM to Strapi migration take?
The pace is set by the inventory and the frontend rebuild, not by the export itself. Exporting packages with Package Manager is usually the shortest step, while mapping fragment models, cleaning asset metadata, rebuilding the frontend and testing redirects take longer. Timing also depends on whether your AEM 6.5 on-premise core support date of February 28, 2027 shapes your decision, since Adobe's support timeline sets that deadline and extended support with critical fixes only runs until February 28, 2028. Ask for a timeline tied to written milestones, and ask how the plan handles a parallel run of the old and new sites before cutover.
Can our own team run the migration without outside help?
Yes, if the team has engineers comfortable with Node.js, a relational database and a React or Next.js frontend, and if someone owns the content model decisions. Strapi 5 supports PostgreSQL 14 or later, MySQL 8.0 or later, MariaDB 10.3 or later and SQLite 3, and runs only on Active or Maintenance LTS Node.js versions, so the platform team must also operate those versions. Many organizations split the work: internal staff own content modeling and editorial sign-off, while an implementation partner handles the export scripts, the import pipeline and hardening. DeployOpen works this way on fixed-scope engagements, where scope, deliverables and timelines are agreed in writing before work starts.
What does the migration need from our internal staff?
Internal staff need to make decisions that no tool can make for them. Content owners must confirm which fragments are current, which are retired, and which locales and brands must survive. Architects must choose the Strapi data model, the authentication approach for end users and the hosting environment. Security staff should review how the Strapi admin panel is accessed, and operations staff must schedule database backups before any upgrade, because the Strapi v4 to v5 documentation says downgrading is not supported. Plan for these people to attend review sessions throughout, not only at launch.
Does Strapi replace AEM page authoring and Forms?
No. Strapi is a headless content store with REST and GraphQL APIs, so it does not provide AEM's page editor, its visual page composition or its Forms capability. Teams that depend on drag-and-drop page authoring must either accept a component-based editing model in the frontend, adopt a separate visual editing tool, or keep AEM for those workflows during a transition. Any form features must be rebuilt in the frontend or supplied by a separate self-hosted tool. Confirm in writing which AEM page and Forms features are in scope before you compare costs.
How do Strapi's Community and Enterprise editions differ for SSO and audit logs?
The Community Edition is MIT licensed and includes the admin panel, REST and GraphQL APIs and unlimited entries and API calls on the free plan. Under Strapi's self-hosted pricing, SSO for administrator login is an add-on on the Growth plan and included in Enterprise, while audit logs and review workflows are Enterprise features. Strapi's SSO applies only to admin panel logins through an identity provider such as Microsoft Azure Active Directory, and end-user authentication is handled by the Users and Permissions plugin. Code under ee directories falls under the Enterprise license unless you hold a signed agreement or a Strapi Cloud subscription, so confirm the licence position with Strapi before you rely on those features.
How DeployOpen scopes and runs an AEM to Strapi migration
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For an AEM to Strapi move, we start with a written scope that separates content fragments, assets and frontend work, so your team knows what is migrated, what is rebuilt and what stays with the existing site.
How we scope
- Inventory AEM content fragment models, assets and the pages that consume them before any work starts
- Agree in writing which content types, locales and asset folders move into Strapi
- Record which AEM page editor features, workflows and personalization rules are out of scope
- Confirm target Strapi edition, Node.js version and database with your platform team
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts
How we build
- Map each fragment model to a Strapi content type, with relations, components and locale settings
- Build export scripts that parse the Package Manager packages into structured JSON and asset files
- Run test imports into a staging Strapi instance and reconcile record counts against the AEM source
- Rebuild the headless frontend as a separate project and connect it to the Strapi REST or GraphQL API
- Generate a redirect map from the old AEM URL structure and test it before cutover
How we hand over
- Document the content model, API endpoints, roles and permissions, and deployment steps for your team
- Provide a runbook covering backups taken before upgrades, since Strapi downgrades are not supported
- Deliver test results for migrated content, asset links and redirect coverage
- Walk your editors through the Strapi admin panel and the review and publishing steps they will use
- Hand over infrastructure as code and configuration so your team can reproduce the environment
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after go-live
- Plan Strapi version upgrades against the release cadence and your change windows
- Keep the redirect map and frontend in step with content model changes during the first months
- Confirm with your team which support tier and identity integration fit your editorial governance
- Quotes follow from the written scope, so ask for line items for each phase and each retainer option
