WordPress Migration ToolingMigration ToolingPlugin DevelopmentWordPress

Move the workflow, not just the form

GF Bundle Porter

A Gravity Forms portability tool that packages operational dependencies, previews target compatibility, remaps account references, and re-encrypts settings for the destination.

Role

WordPress Plugin Developer

Timeline

June 2026–present

Status

Version 1.0.0 implementation

Client

WordPress migration workflow

Diagram showing a source WordPress site exporting forms, add-on feeds, Salesforce feeds, account references, and optional settings into a bundle that is previewed and imported on a target site.

01 / The problem

A workflow that needed stronger engineering boundaries

Moving a Gravity Form between WordPress environments does not necessarily move the add-on feeds, CRM connections, object mappings, or global settings that make it operational. Recreating those dependencies manually is slow and error-prone, especially when destination IDs and encryption keys differ.

A migrated form appears present but loses payment, CRM, partial-entry, or custom add-on behavior
Source database IDs do not map safely to the destination
Feed metadata encrypted on one site is unusable on another
A missing add-on leaves imported configuration in an ambiguous state
A partial failure creates orphan forms, feeds, or CRM accounts
Portable bundles expose credentials or tokens if handled as ordinary JSON

02 / The approach

Design the workflow around explicit invariants

Create a portable, schema-versioned representation that separates logical references from source IDs, then insert a mandatory preview between upload and mutation. During import, create a new form through Gravity Forms, rebuild supported feed rows, resolve CRM accounts by name, re-encrypt destination-owned settings, warn or skip missing dependencies, and track created records for recovery.

Complete operational bundle: Package form definitions with generic add-on feeds, CRM Perks feeds/accounts, and optional global settings.
Preview before mutation: Show source, version, forms, fields, feed counts, add-on availability, settings, and warnings before confirmation.
Logical reference mapping: Resolve CRM accounts by name and let Gravity Forms allocate new form IDs instead of reusing source identifiers.
Destination-aware restoration: Re-encrypt compatible feed metadata and add-on settings with the destination site's facilities.
Recoverable import: Record newly created forms, feeds, and accounts and delete them in reverse order after a critical exception.

03 / Architecture

Gravity Forms add-on with separate exporter and importer services

The implementation separates WordPress integration points from the domain services and operational controls that carry the workflow.

WordPress/Gravity Forms bootstrap
Capability- and nonce-protected admin interface
Exporter for form, feed, account, and global-setting collection
Schema validation and user-scoped preview staging
Importer for compatibility checks, mapping, insertion, encryption, warnings, and rollback
Shell build script for a clean WordPress ZIP

04 / System surface

Capabilities organized around the operator journey

The case study focuses on the verified engineering surface rather than unmeasured business claims.

Export: Select one or more Gravity Forms
Export: Use Gravity Forms' prepared export structure for form definitions
Preview and compatibility: Validate a GF Bundle schema and 5 MB upload limit
Preview and compatibility: Display source/GF/plugin metadata and per-form field/feed counts
Import: Create destination forms with new IDs
Import: Rebuild installed add-on feeds and skip missing dependencies with warnings
Safety and delivery: Administrator capability checks and CSRF nonces
Safety and delivery: Preview/confirm separation with user-scoped expiring transient

05 / Engineering decisions

Tradeoffs made explicit

The design choices below address compatibility, identity, safety, and maintainability constraints found in the audited implementation.

Extend Gravity Forms' prepared form export instead of replacing it: The native structure remains the authority for form fields and settings while the bundle adds missing operational dependencies.
Use a versioned JSON schema: Schema identity supports validation and leaves room for controlled evolution and legacy-shape normalization.
Resolve CRM accounts by name: Source database IDs have no stable meaning on the destination site.
Preview compatibility before confirmation: Operators can see missing add-ons, feed volume, included settings, and encryption warnings before data is created.
Skip unavailable add-on feeds with explicit warnings: A missing optional dependency should not necessarily invalidate every form in a multi-form bundle.
Track inserted records for reverse-order rollback: A critical exception should not leave newly created forms, feeds, or accounts orphaned.

06 / Verified outcome

A defensible result grounded in inspected evidence

Repository and interface evidence establish the engineering outcome. Production volume, time savings, and business impact remain unclaimed unless separately confirmed.

The version 1.0.0 plugin is implemented in four PHP files totaling 1,237 lines at commit 5a8b9fe42f6180368a8ea4090ab2768a9306294c.
The bundle schema supports multiple forms, generic add-on feeds, CRM Perks feeds/accounts, and optional global settings.
The admin workflow separates export, upload/preview, and confirm actions with administrator capability and nonce checks.
The importer tracks newly created forms, add-on feeds, CRM feeds, and CRM accounts for reverse-order cleanup after a critical exception.
A build script creates a versioned WordPress plugin ZIP containing only runtime PHP files.
Operational form configuration becomes one portable package rather than a manual recreation checklist.
Preview and warning states make dependency differences visible before confirmation.
Logical account references and destination encryption address two common cross-site portability failures.