Drupal Webforms to WordPress: Plan Forms, Submission Data and Access
Move Drupal forms with a plan for submission history, attachments and staff access. Separate the working form rebuild from the historical data handover.
In this article
Editorial illustration. Any screens and records are illustrative, not a delivered client system.
A Drupal form can represent years of applications, enquiries or document requests. Rebuilding the visible fields in WordPress is only one part of the move. The team still needs to find older records, understand their meaning and receive new submissions through the right route.
A dedicated Drupal Webform to WordPress migration brief separates the working form, the historical data and the processes around them. That separation makes estimates more reliable and prevents an attractive replacement form from hiding an unresolved data handover.
Inventory forms by business purpose and owner
List each active Webform, its public URL, the team responsible for it and the task it supports. Include embedded forms that are easy to overlook, seasonal forms that are currently closed and older forms whose records still need to be retained. Confirm which forms should actually be rebuilt.
For every form, record required fields, conditional questions, confirmation messages, permitted file uploads, notification recipients and downstream systems. Ask the business owner which behaviour is essential. Unused fields and obsolete notifications should not automatically become part of the new implementation.
My broader Drupal to WordPress planning guide covers the surrounding site migration. The form inventory here becomes a specific workstream within that larger plan.
Separate rebuild, archive and historical import decisions
The Drupal Webform documentation describes submission management and CSV download capabilities. An export provides source data; it does not automatically recreate conditional logic, notifications or a working destination form.
Choose a destination for the history deliberately. A team may need a controlled archive for occasional reference, selected records in a CRM, or a supported import into its chosen form system. These are different deliverables. Do not assume an import exists because a destination product can export its own records.
For example, Elementor’s form-submission documentation explains its submission management. A Drupal-history import still needs its own compatibility check, field mapping and acceptance criteria.
Create a field map that preserves meaning
A field label alone may not explain the stored value. Record identifiers, option values, display labels, multiple selections and blank-versus-unanswered behaviour. For dates, agree the timezone and display format. For files, distinguish the submission’s reference from the actual file and its access requirements.
| Source detail | Destination decision |
|---|---|
| Submission identifier | Preserve a stable reference for reconciliation |
| Option value and label | Map both when they have different meanings |
| Multiple selections | Keep separate values rather than an ambiguous text string |
| Created date and timezone | Preserve the date meaning and label the display timezone |
| Uploaded file reference | Confirm the file exists and the intended people can open it |
| Consent or acknowledgement record | Retain approved wording/version context where required |
This is a planning example. The final map depends on the source configuration and the destination chosen for your organisation.
Decide who may see and change historical records
Submission history can include personal or commercially sensitive information. Agree which staff roles need to view records, download files, export a selection, edit a status or delete an entry. Do not make a private file public merely to simplify a migration.
Have the organisation’s responsible owner approve retention and disposal decisions. A developer should implement the agreed rules, not invent a legal retention period. Use anonymised or artificial sample records during early mapping where possible, and define how authorised migration access ends after handover.
If the destination is a custom CRM rather than a form archive, distinguish read-only historical context from active work that will trigger new reminders or follow-ups. Imported history should not unexpectedly restart old customer communications.
Rebuild the new submission journey before the final transfer
Agree the destination form product and check its required field types, conditional behaviour, attachments and editable presentation. Include mobile number formatting, clear validation, keyboard use and a readable confirmation state. Keep the visible form manageable rather than copying every legacy field without review.
Document each post-submission action separately: saved record, staff notification, customer acknowledgement and CRM transfer. Define what staff should do when one action fails. A form can save an entry while a notification or integration fails, so a single green success message is not a complete operational check.
Through Drupal to WordPress migration development, I can scope this rebuild alongside the data and content work, with clear boundaries around third-party products and unsupported integrations.
Run a sample transfer with a reconciliation ledger
Choose a representative sample that includes long answers, older option labels, attachments, multiple selections and unusual characters. Compare the source and destination field by field before moving the full approved set. Record exceptions rather than silently dropping a value that does not fit.
- Count the source records included in the agreed scope.
- Map each record to a stable destination or archive reference.
- Check representative values, dates, selections and file access.
- Document exclusions, rejected rows and the reason for each.
- Have the business owner approve the sample and any transformation rules.
A matching total is useful, but it does not prove that every field retained its meaning. Pair record counts with sample-level checks and a documented exception list.
Plan the changeover while enquiries continue
Decide which system receives submissions during the transfer window. If Drupal remains live while WordPress is being prepared, new records may arrive after the first export. The release plan needs a final collection or controlled handover of that difference, rather than assuming the first export stays current.
Name the person who approves the cutover and the person who checks incoming enquiries afterwards. Agree whether notifications should be suppressed during an authorised import, and distinguish imported historical rows from new live submissions. Any test messages should be labelled and sent only to agreed recipients.
Include a recovery decision and a way for staff to identify the active system. Confusion about which inbox or dashboard to check can undermine an otherwise accurate transfer.
Request a proposal with separate form and data deliverables
Send the form inventory, approximate record counts, date range, attachment types and intended destination. Include the staff roles involved and the business reason for retaining the history. A redacted sample is more useful initially than sending a complete export containing customer details.
I can prepare a scoped Drupal forms and WordPress migration proposal covering the field map, form rebuild, supported history handover, sample reconciliation and release checks. That allows you to approve the work against observable records and behaviour, rather than judging the migration only by how the new form looks.
Written by
Jagjeet Singh
Full stack development, WordPress engineering and practical web products. I work with businesses, teams and agencies in India and worldwide.
Explore my work
