Drupal 7 Webform migration: what the move involves and how long it takes
If your Drupal 7 site has live forms and stored submissions, the move to a supported Drupal version has to happen as a new build, not an in-place upgrade, and it has to be scoped before support runs out. Drupal 7 security support ended on January 5, 2025, according to Drupal.org, so every month on the old platform adds exposure for public forms that collect personal data. The effort depends mainly on how many forms you have and how many of them are simple contact or feedback forms versus multi-page forms with conditional logic, file uploads, handlers that send data to other systems, and custom validation. Drupal.org documentation says Drupal 6 and 7 sites cannot simply be updated to Drupal 10 or later; they are migrated into a new site with the core Migrate, Migrate Drupal and Migrate Drupal UI modules or with Drush, and themes must be rebuilt.
The Webform: Migrate project provides migration routines from Drupal 6 and 7 Webform to the current Webform module. Its latest stable release, 8.x-1.2, supports Drupal ^8.8 or ^9. Check that constraint against your target site before scoping anything, because a target on Drupal 10 or 11 may need a different path or a newer release of the bridge. Confirm the exact compatibility of the Webform and Webform: Migrate versions you plan to use with the project page and your own test build, not with assumptions carried over from older guides.
Ask your partner to inventory every webform, its handlers, and the submission count per form, then classify each form as simple or complex. Simple forms with standard fields are usually the cheapest to carry across. Complex forms need a separate rebuild or a tested mapping, and the submission data behind them must be checked field by field after each trial run. Quotes should show the number of forms in each class, whether submissions are migrated or only archived, and who signs off on the test results. Treat rebuilding and testing as separate line items so the cost of each form is visible.
Which Webform features migrate cleanly and which need rebuilding
This table compares common Drupal 7 Webform elements, settings, handlers, submissions and access rules against their handling in the current Webform module. Use it to sort your forms into three groups: items the Webform: Migrate module is expected to carry over, items that arrive only partly, and items you should plan to rebuild by hand. Confirm each row against the module's documentation on its project page before you rely on it.
| Feature | Migration expectation | What to plan for |
|---|---|---|
| Basic form elements (textfield, textarea, select, checkboxes, radios, date, email) | Expected to migrate with the Webform: Migrate routines | Check each element's options, default values and required flags on a staging copy |
| Submissions and their stored values | Expected to migrate, subject to the module's coverage notes | Compare record counts and sample entries; confirm how deleted or draft submissions are handled |
| Form-level settings (confirmation message, redirect, submit label) | Partly covered; confirm which settings the routines map | Re-enter any setting the routines skip and retest the confirmation flow |
| Conditional logic (show or hide based on other fields) | Maps only partly; Drupal 7 rules often need translation | Rebuild and test each rule in the current Webform conditional settings |
| Multi-step wizards and page breaks | Maps only partly; page structure and navigation may differ | Redesign multi-page flows and test partial saves and back navigation |
| Custom validation (Drupal 7 hooks or custom code) | Not expected to migrate; code must be rewritten | Inventory every custom validator and rebuild it as a Drupal 10 or 11 module or handler |
| Email handlers and notifications | Maps only partly; templates and recipients need checking | Recreate handlers, token use and recipient logic, then send test messages to a controlled mailbox |
| Other custom handlers or integrations (CRM, API posts) | Not expected to migrate | Rebuild as new handlers or services and test failure paths |
| Access rules and submission permissions | Partly covered; role names and per-form grants need review | Map each Drupal 7 permission to a current role and verify access on every form |
| Themes and form markup | Not migrated; themes are rebuilt, not converted | Rebuild templates and styling in the new theme and run accessibility checks |
Documented migration tools for Drupal 7 Webforms
Drupal 7 Webforms move to the current Webform module through a small set of documented paths, and each one covers a different layer of the work. Read them together: the Webform: Migrate routines handle form definitions and submissions, the core Migrate tooling moves the surrounding site, and the Migrate API covers anything the other two leave out.
Webform: Migrate module
This contributed module provides migration routines from Drupal 6 and 7 Webform to the current Webform module. It is the first tool to evaluate for form definitions and stored submissions, because it is built for this specific conversion. Confirm on its project page which Drupal core versions the latest stable release supports, since the target site must match that compatibility before any routine runs. Test with a copy of production submissions, not only sample forms.
Core Migrate and Migrate Drupal
The core Migrate, Migrate Drupal and Migrate Drupal UI modules move a Drupal 6 or 7 site into a new Drupal site, covering content, users, configuration and files. They are used for the site-level move, so the form layer is one part of a larger job. They do not carry themes, which must be rebuilt by hand. Decide early whether forms migrate in the same run as content or in a separate pass, so that dependencies such as roles and text formats are already in place.
Drush for scripted runs
Drush runs the migrations from the command line, which suits repeatable test runs and production cutovers. Scripted runs make it possible to repeat the same sequence against a fresh copy of the database until the output matches expectations. Ask your team or partner to record the exact commands, module versions and migration order so that the run can be reproduced during a rollback or audit. Drush does not decide whether a form should be rebuilt; it only executes the migrations that exist.
Migrate API for custom data
The Migrate API lets developers write custom migrations for data that the documented routines do not cover, such as forms with unusual field types, submission fields tied to custom code, or records joined from an external system. It gives full control over source, mapping and destination, but every custom migration becomes code the organization must maintain. Plan for source-to-destination mapping tests and for rollback behavior, because partial runs can leave orphaned submissions.
Where the tools stop
No documented routine guarantees that a complex Drupal 7 form will behave the same way on the Webform module. Conditional logic, custom validation, handlers that send email or write to other systems, and multi-page wizards often need to be checked and rebuilt. Inventory each form by its handlers and conditions before choosing a path, and treat any form that depends on custom Drupal 7 code as a manual rebuild item in the scope.
Core compatibility and planning checks
Confirm three things before estimating the work: the target Drupal core version, the Webform module release that supports it, and the PHP version the target requires. Drupal 6 and 7 cannot be updated in place, so the form layer always moves into a new site. Check the Drupal system requirements for the target and the Webform: Migrate compatibility notes together, and record any gap as a blocker rather than a workaround.
How the form migration sequence runs from inventory to decommission
The sequence moves each Drupal 7 webform and its submission history to the current Webform module in a controlled order, with a checked result at every stage before the old site is retired. Each phase ends with evidence that the forms, data and routing behave as expected.
Inventory every webform and its dependencies
Start by listing every webform on the Drupal 7 site, along with its handlers (email notifications, integrations, post-submit actions), access rules by role, multistep or conditional logic, and submission counts per form. Record which forms are still in active use, which are referenced by pages, menus or other modules, and which can be retired. Your team and DeployOpen can run this together, with the output being a signed-off register that marks each form as migrate as-is, rebuild by hand, or retire. Confirm the submission volumes with the business owners, since they set the size of the data migration and archive.
Pilot the migration on a copy of the database
Restore a copy of the Drupal 7 database and files into a non-production environment, then install the target Drupal site with the core Migrate, Migrate Drupal and Migrate Drupal UI modules and the Webform: Migrate module. Run the Webform migration routines against a small set of representative forms, including one with handlers and one with restricted access. Compare the migrated form definitions and a sample of submissions with the originals. The pilot is complete when the results are logged, each defect has an owner, and the team agrees which routines must be fixed before the full run.
Rebuild complex forms and verify field mapping
Forms that rely on custom handlers, unusual element types or logic the migration routines do not carry across are rebuilt by hand on the new site. For each rebuilt or migrated form, check every element, its validation, required flags, default values and conditional rules against the register from the inventory. Confirm that handlers send emails and integration calls to the same destinations and that submission field keys still map to the stored data. The step closes when a field-by-field mapping sheet is signed off for every form in scope.
Rebuild the theme for the new site
Drupal 6 and 7 themes cannot be migrated to current Drupal, so the form markup, layout and styling must be rebuilt in a current theme. Form pages should be reviewed on the target theme for layout, error messages, accessibility of labels and focus order, and mobile rendering. Check that the rebuilt styles do not break form elements that the migrated webforms depend on. The step is done when each form page is reviewed in the target theme and the review notes are closed.
Run a parallel period with identical test submissions
Keep the Drupal 7 site and the new site live in parallel for a period agreed in advance. Submit the same scripted set of test entries to both sites, covering valid input, invalid input, edge cases and each handler path. Compare the stored submissions, notification emails, integration records and error messages. Differences are logged and classified as defects or accepted changes. The step is complete when both sites produce matching results for the agreed test set and every open defect is resolved or formally accepted.
Cut over DNS or routing to the new site
Plan the cutover with the hosting team, covering DNS changes or load balancer and reverse proxy routing, TLS certificates, redirects from old form paths, and any external links or embeds that point at the Drupal 7 forms. Freeze form changes on the old site before the final data sync, run the final submission migration, and repeat the checks from the parallel period on production. The step closes when forms load and submit correctly on the new routing, redirects return the expected responses, and the cutover record is signed off.
Archive submissions and decommission the Drupal 7 site
Export the Drupal 7 submission data and any attachments to an archive that meets your retention policy, then verify the archive by sampling records and checking counts against the inventory figures. Only after the archive is confirmed and the business owners accept the new site should the Drupal 7 site be shut down. Confirm with your security and compliance leads how the archive is stored, access controlled and eventually deleted. The sequence ends when the archive check is recorded, the old site is switched off, and its credentials and hosting are removed.
What drives the cost and duration of a Webform migration
This table lists the factors that change the effort of moving Drupal 7 webforms and submissions to the current Webform module, and who typically pays for each part. Read it as a checklist for scoping: the rows that involve the most custom work are usually the ones that move a quote most. Ask for each driver to be counted in the written scope before work starts.
| Driver | Why it changes cost or effort | How to keep it down |
|---|---|---|
| Number and complexity of forms | Each form needs a mapped target, and forms with many element types, custom validation or nested components take longer to check than simple contact forms. | Inventory every form, retire unused ones and group similar forms into one review pass. |
| Conditional logic and multi-step forms | Conditions, wizard pages and dynamic fields may not carry over exactly, so each one may need rebuilding and retesting by hand. | Agree which behaviors must match the old form and which can be simplified before the build. |
| Custom handlers and CRM or email integrations | Handlers that post submissions to a CRM, mail server or other system are custom code that must be rewritten or reconfigured, and each endpoint needs test credentials. | List every destination, confirm who owns each endpoint and request sandbox access early. |
| Volume of stored submissions | Migrating large submission sets takes longer to run, verify and roll back than a small set, and storage needs grow with retained history. | Set retention rules first and migrate only the submissions the business must keep. |
| Retention and data handling rules | Rules on how long submissions are kept, and whether personal data in them is purged, add review and scripting work that is separate from the copy itself. | Document the retention policy and decide with the data owner which records are archived, deleted or excluded. |
| Access and permission models | Per-form roles, results access and anonymous submission settings must be mapped to the new site, and each role needs testing. | Reduce the role model to the roles that exist in practice and test them with named users. |
| Target Drupal version and PHP requirement | Drupal 6 and 7 sites are migrated into a new site rather than updated in place, and the target version sets the PHP version the new environment needs. Drupal 10 requires PHP 8.1 or later, Drupal 11 requires PHP 8.3 or later and Drupal 12 requires PHP 8.5 or later, according to the Drupal.org PHP requirements page. | Choose the target version and PHP version before the build so that module compatibility is checked once. |
| Theme rebuild | Themes cannot be migrated, so form markup, styling and layout around each form are rebuilt for the new theme, which can be significant for branded or accessible forms. | Reuse an existing front-end design system and limit form templates to a small set of patterns. |
| Verification and sign-off | Each form needs test submissions, notification checks and sign-off by the form owner, which is often the largest part of effort after the build. | Agree a test script per form and name who signs off before the project starts. |
What usually goes wrong with Webform migrations and how to prevent it
Webform migrations rarely fail loudly. Submissions arrive with missing values, handlers stop firing and forms behave differently once rebuilt, so the problems surface weeks later. The cards below cover the failures we see most often and the check that catches each one before cutover.
Submissions missing field types and timestamps
Submission rows can load while typed values, such as dates, files, select options and timestamps, arrive as plain strings or blank cells. Reports and exports then look correct on the surface but sort, filter or total incorrectly. Before cutover, compare a sample of submissions field by field against the Drupal 7 database, including the submission created and completed times and any uploaded files. Confirm that the migrated data keeps its original time zone handling.
Handlers that silently stop sending
Email notifications, remote post handlers and custom handler logic may not carry across in the same form. A form can save submissions normally while nobody receives the message it was built to send. Inventory every handler on each Drupal 7 webform, then send a test submission through each one on the new site and confirm delivery at the receiving end. Treat any handler without a confirmed test as unfinished.
Conditional rules that change after rebuild
Conditional show and hide logic, and multi-step page flow, can be translated into a different rule set in the current Webform module. Fields may appear for the wrong answers or validation may fire at a different step. Write down the expected behavior for each conditional rule from the Drupal 7 form, then walk every branch on the new form, including empty and edge-case answers. Complex forms should be rebuilt and tested by hand rather than trusted from the import.
Spam and access settings lost in transfer
Anti-spam protection, submission limits, who may view results and who may edit submissions are configuration rather than content, so they are easy to omit. A form that worked behind a CAPTCHA can become open to bots, and a results page may expose data to roles that never had access. Record each access and spam setting from the old site, set them explicitly on the new forms, and test with anonymous and each authenticated role.
Running an unsupported Drupal 7 site
Drupal 7 security support ended on January 5, 2025, and projects that run long migrations keep forms receiving personal data on an unsupported platform. Ask whether the migration will be fast enough to avoid an extended support contract, or whether the old site needs temporary hardening. Freeze new webform changes during the project so the migrated submissions match the live data at cutover.
Questions buyers ask before moving Drupal 7 webforms
Can our own team migrate Drupal 7 webforms without a partner?
Yes, if your team has Drupal 7 and current Drupal experience, a staging environment and time to test each form. The core Migrate API, Migrate Drupal and the Webform: Migrate module handle the mechanical part, but someone still has to inventory forms, check every handler and confirm that the rebuilt forms behave the same way. Teams without recent Drupal migration work usually find the review and testing steps take longer than the import itself. A partner is most useful when forms carry custom logic, many integrations or a tight deadline. Ask your team to list the forms and handlers first, then decide which parts to keep in-house.
What drives the cost and effort of a webform migration?
The main driver is how many forms your site has and how much each one does beyond collecting fields. Costs come from four areas: the form and handler inventory, the migration run and its fixes, rebuilding forms that the module cannot carry across, and testing with the people who own each form. Simple contact forms cost little to move. Forms with conditional logic, file uploads, payment steps or handlers that post to external systems cost more because each one needs a design decision and a test. Work is mostly one-time. Ongoing costs are maintenance of the rebuilt forms and any integrations. When you request a quote, ask for the cost of each form category separately and for the assumptions behind the testing hours.
How long does a Drupal 7 webform migration take?
The timeline depends on the form count, the number of complex forms, the number of integrations and how quickly stakeholders can review rebuilt forms. Migration of the data is usually the shortest step. Most of the calendar time goes to inventory, rebuilding forms by hand, and sign-off from business owners who must confirm validation rules, emails and routing. Compliance or accessibility review can add time if those forms collect regulated data. Because the Drupal 7 site is also moving to a current Drupal version, the webform work often runs alongside theme and module work, which can set the critical path. Ask for a schedule that lists each form category and the approval gate for each.
What must our team provide before the migration starts?
Your team needs to provide three things. First, a form inventory that lists every webform, its owner, its fields, its handlers, its access rules and its current usage. Second, access to the Drupal 7 database and file system in a copy that can be restored, so the migration can be run and rerun in a safe environment. Third, named reviewers who can sign off on each rebuilt form, including validation, confirmation messages, notification recipients and data retention. Without these inputs, the migrated forms may look correct but fail in production. Confirm with your partner or internal team who holds each responsibility before work begins.
Does Webform: Migrate move all submissions and handlers?
Webform: Migrate provides migration routines from Drupal 6 and 7 Webform to the current Webform module, so it covers the core form structures that the module supports. Do not assume it moves every submission and every handler without checking. Confirm for each form whether its fields, submission data, email and other handlers, and settings map to the current Webform module. Custom handlers, uncommon field types and logic added by custom code usually need to be rebuilt. Run the migration on a copy, compare submission counts and sample records, and test each handler with a test submission before you cut over. The latest stable release, 8.x-1.2, supports Drupal ^8.8 or ^9, so confirm the release works with your target Drupal version before you plan around it.
What should we do if the site cannot move before support is needed?
Drupal 7 security support ended on January 5, 2025, according to Drupal.org. The Drupal Association's Extended Security Support Provider Program lists HeroDevs and Tag1 Consulting as certified vendors for sites that cannot migrate yet. Staying on Drupal 7 without that cover leaves known vulnerabilities open, and that risk grows over time. If a migration cannot happen soon, ask what the extended support covers, how long it runs, and what it costs before you commit. Keep the Drupal 7 site behind tighter access controls, limit public form exposure where possible, and plan the webform migration as a separate phase so the forms can move first if needed.
Can we keep Drupal 7 forms running while we rebuild them?
Yes, many teams run the old and new forms side by side for a period. Keep the Drupal 7 site in place as the source of record, and point live traffic to the rebuilt forms only after each one passes review. Use a clear cutover date for each form, and capture submissions on both sides during the overlap so no data is lost. Decide early how submissions made on the old site will be merged or archived in the new one. Route notifications carefully during the overlap, since duplicate emails to staff or customers are a common problem. Document the cutover order for every form so your team can roll back a single form without affecting the rest.
Does DeployOpen plan and rebuild Drupal webforms for our site?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, including Drupal. For webform work, that can include the form inventory, running the migration on a copy, rebuilding complex forms, integrating handlers with your systems and documenting the result. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. A quote follows from that written scope, and DeployOpen does not publish a price list.
How DeployOpen scopes a Webform migration before any build starts
DeployOpen works from a written, fixed scope, and the scoping phase comes before any migration code is written. The first step is an inventory of the Drupal 7 site: every webform node, its components, its handlers (email, save-to-database, remote post), its conditional logic, its access settings and its submission volume and retention. The second step is a mapping review, where each Drupal 7 component type is matched against what the current Webform module and the Webform: Migrate module can carry across, and where it cannot. Only after both steps does the reader receive the scope document and a quote. Confirm with the Webform: Migrate project page which Drupal 7 component types and handler settings it covers in the release you plan to use, because coverage is the single biggest driver of how much hand work remains.
The scope document lists three groups. The first is forms that migrate with their structure, submissions and handlers intact after a test run. The second is forms that DeployOpen rebuilds by hand in the new site, typically multi-step forms, forms with heavy conditional logic or custom validation, and forms that call custom Drupal 7 code. The third is open questions that must be answered before the quote is final, such as which submission history must be kept, whether retired forms can be archived instead of moved, and who owns the decision on each email recipient list. The migration itself is planned and implemented inside your own infrastructure, in the hosting, database and staging environments you control, so submission data never leaves systems you approve. Ask for this three-part list in any proposal you receive, from DeployOpen or another partner.
Because Drupal 7 sites cannot be updated in place to a current version, the scoping work also decides the target platform, PHP version and module list for the new site. The current core requirements, which are listed on Drupal.org, mean the target must run a supported PHP version, so confirm your hosting can meet that before committing to a date. The scope should state who signs off on the form list, who tests each rebuilt form against its original behavior, and how many test cycles are included. These are the points where a fixed scope protects both sides from later change requests.
How DeployOpen works on this
DeployOpen plans, builds, documents and supports Drupal 7 Webform migrations inside your own infrastructure, starting from a written scope. We inventory your forms and submissions first, test the Webform: Migrate path against your data, and rebuild the forms it cannot carry over before handing the site to your team.
How we scope
- Inventory every Drupal 7 webform, its components, handlers and submission volumes before estimating work.
- Record which forms the Webform: Migrate module covers and which need manual rebuilding, in writing.
- Agree the written scope, deliverables and timeline before work starts, as most engagements are fixed-scope.
- Confirm the target Drupal version and PHP version with your team so the Webform module choice is compatible.
How we build
- Set up the new Drupal site and install the Webform and Webform: Migrate modules in a non-production environment.
- Run test migrations of forms and submissions, then compare field counts, types and sample records against the source.
- Rebuild complex forms by hand, including conditional logic, multi-page flows and custom handlers, and test each one.
- Check email notifications, file uploads and access settings on rebuilt forms before any cutover is scheduled.
How we hand over
- Document the form inventory, mapping decisions, manual rebuilds and known gaps so your team can maintain them.
- Provide the migration scripts, configuration exports and a rollback procedure you can rerun.
- Walk your content and developer staff through how forms, submissions and retention settings are managed after launch.
- Record the test results and sign-off steps that your internal audit or compliance team can review.
How we support
- Offer ongoing support, module updates and security patching for the migrated forms as a retainer, if you want it.
- Monitor Drupal security releases and module updates so the Webform setup stays on supported versions.
- Schedule follow-up fixes for form issues found after launch within the agreed support arrangement.
- Confirm with your team which support tier, response expectations and recurring costs apply before the engagement ends.
