Loading...
Loading...
Drupal → Sanity port
Move routine publishing off Drupal. The written scope states the maintenance model that replaces its hosting, patching and upgrade work.
Three routes
An upgrade is the cheaper answer when Drupal is not the real problem. I tell you which of the three I think fits, after the content audit.
Your modules are healthy and your team is not blocked. Take the version step and keep the platform.
Your Drupal partner scopes and quotes this route, not me.
Your design is fine and your team is blocked on publishing. Move the content model and the pages as they are today onto Sanity and Next.js.
Scoped in writing after the content audit.
You need a new information architecture, new page templates, new roles and a new approval process. That is a project, not a move.
Scoped as a project, in writing, after the content audit.
Who does the work
Scope
The process
The content audit decides a Drupal move, and the written scope comes after it. My delivered proof is on the Sanity and Next.js side. Your review time sets the launch date. You approve the scope before the build starts.
You and I agree the pages in scope and who decides. We also agree the accessibility standard you must meet.
Output: A written scope and a set of control rules.
I list content types, fields, Paragraphs, vocabularies, Views, modules, URL families and languages. You mark what the organisation cannot lose.
Output: A field-level migration map, a verdict on every module, and my route recommendation.
I write the Sanity schema and the block library, set the roles, and stand up a staging dataset. You supply the access.
Output: A content model your editors can see, and a staging site.
I run the import as a repeatable script against staging. Then I rebuild the page templates and the listings.
Output: A full staging site, with a count of every item that moved.
I check the redirect map, the item counts, the metadata and the accessibility standard. You review staging and send one list.
Output: An acceptance checklist and the fixes against the agreed migration map.
I record the rollback point, launch, watch Search Console, and train your editors on the new tool.
Output: A live site, an editor guide, a rollback point and a training session.
If you want AI in it
The CMS works with AI switched off, and most teams start that way. If you include it, these controls become acceptance requirements in the written scope, at step 1.
Safeguards
A Drupal move puts your search results, your accessibility duty and your launch date at risk. Here is what holds each one down.
Questions
If your modules are healthy and the team is not blocked, compare an upgrade with a replacement. For an older Drupal site, get both scopes in writing before committing.
Views become queries written in code, next to the page that uses them. I rebuild every listing on the migration map. We agree that map at step 2, before any work starts. A new listing after launch needs a developer. Your editors can no longer build a listing on their own. That is the real trade.
I put every module in a verdict list at step 2. For each one I mark a single verdict. Migrate the content it holds. Rebuild the job it does in the front end. Or drop it, because it is front-end only. If the original developer is gone, that audit comes before any scope.
Sanity does not render your public pages, so the markup is mine to control. There is no theme layer in the way. I test against the standard named in your scope, before launch. The editor tool itself is only partly conformant, and I will show you the vendor statement. A formal audit and sign-off stays with a specialist.
It is the main risk, so it gets the most attention. Drupal makes several kinds of URL: node paths, aliases, term pages and Views listings. I map all of them to redirects before the move, then test them on staging. I watch Search Console after launch. I cannot promise a ranking.
Forms move to a form service, or to a simple form handler I build. I port or archive the submissions, to your data policy. I drop nothing without telling you. A member login area does not move, because Sanity has no login for site visitors. That needs a separate service, and I scope it separately.
I provide Sanity's current hosting, data-processing, sub-processor and contractual documents. Your procurement and data-protection teams decide whether they meet your requirements. The content store is vendor-hosted.
You own the site, code and accounts. The written scope states the warranty and compares the ongoing CMS, hosting and maintenance costs. Your procurement team validates the forecast.
You own the code, the content and the accounts from day one. The stack is Next.js, Sanity and Vercel, and another agency can pick it up. I hand over a written schema map and an editor guide before launch. You can also name your own agency in the scope, so a second team knows the build.
Send the Drupal URL, the current version and the latest upgrade scope. I will return a written upgrade-or-exit view and state whether a written content audit is justified.
Send me your Drupal URL