Migrating from other plugins

If you’re already running another table or entry-display plugin, this page covers the migration path to Gravity Tables. The good news: in most cases your data doesn’t move, only the rendering layer.

General principle#

Gravity Tables reads from the standard Gravity Forms entries table. It doesn’t store entries separately, doesn’t run its own database, and doesn’t lock data into a proprietary format. Migration is overwhelmingly a matter of:

1. Installing Gravity Tables
2. Building a table that points at the same form
3. Replacing the old plugin’s shortcode with [gravity_table id="..."]
4. Optional: copying any field-mapping or styling decisions over

Your existing entries are untouched.

From GravityView#

GravityView (honest comparison) is the closest peer. It renders Gravity Forms entries with rich layouts (single-entry pages, maps, directories). Migration is straightforward when you want to flip from “directory display” to “interactive table”.

What carries over#

• Form data, same Gravity Forms entries, no migration needed
• Field labels, Gravity Tables uses the same label/admin-label/field-ID identifiers GravityView uses

What changes#

• Layout style: GravityView’s drag-and-drop visual editor → Gravity Tables’ shortcode-first config
• Per-view permissions: GravityView’s view-level role gates → Gravity Tables’ allowed_roles shortcode parameter
• Single-entry detail page: GravityView renders these natively; Gravity Tables doesn’t have a built-in detail view (link to your form’s confirmation page or use a separate plugin if you need it)

Migration steps#

1. Note your GravityView view’s form ID and visible fields
2. Tables → Add New → pick the same form, select the same fields
3. Replace [gravityview id="..."] with [gravity_table id="..."] on the page
4. Decide if you still need the GravityView view (you may want both during transition)

From wpDataTables#

wpDataTables (honest comparison) is source-agnostic, it can pull from MySQL, CSV, Excel, JSON, Google Sheets. If your data lives outside Gravity Forms, Gravity Tables is not a drop-in replacement.

The right migration for wpDataTables users depends on where the data lives:

If data is in Gravity Forms entries (via the GF add-on)#

This is the easy case. Map columns 1:1, replace the shortcode:

[wpdatatable id=12]

Becomes:

[gravity_table id="12"]

If data is in a custom MySQL table#

Gravity Tables doesn’t read arbitrary MySQL. Two options:

1. Stay on wpDataTables, it’s the right tool for non-GF SQL data
2. Use TableCrafter (sister plugin), reads JSON, CSV, Google Sheets, REST APIs. Same design philosophy as Gravity Tables.

If data is in CSV or Excel files#

Use TableCrafter (point it at the file URL or upload). Migration is a config swap.

From GP Nested Forms#

GP Nested Forms (honest comparison) is a different layer, it shapes how a form is collected (parent entry with child rows). Gravity Tables shapes how entries are displayed afterwards.

You don’t migrate from GP Nested Forms. You add Gravity Tables on top of it. Display the parent entries in a Gravity Tables view, and use a custom column to show the child-count or summary.

[gravity_table id="quotes" filters="status,date" totals="amount"]

The “amount” column in the parent quote entry can be the GP-calculated total of child line items.

From Posts Table Pro#

Posts Table Pro (honest comparison) tables WordPress posts and WooCommerce products, completely different data source. Migration is not applicable unless you also migrate your data into Gravity Forms entries (rare).

The only case worth considering: if you’ve been using Posts Table Pro as a stand-in for “entries-as-table” because it was the closest fit, and you’re willing to convert your data flow to capture entries via Gravity Forms going forward. That’s a project, not a migration.

From TablePress#

TablePress (honest comparison) is for static, hand-edited tables. If you’ve been hand-editing rows in TablePress for data that should come from form submissions, Gravity Tables is a major workflow improvement.

Migration steps#

1. Build a Gravity Form that captures the same fields you’ve been hand-typing
2. Import existing TablePress rows via the GF Import/Export plugin (or a one-time CSV → GF API script)
3. Build a Gravity Tables table pointing at the new form
4. Replace [table id=X /] with [gravity_table id="..."]

You now have a real database-backed table where users can submit rows via the form, and you can edit existing rows inline via allow_edit.

From Ninja Tables#

Ninja Tables (honest comparison) supports manual entry, CSV upload, Fluent Forms integration, and Google Sheets. If your data is in Fluent Forms, Ninja Tables is the right choice; we don’t have a Fluent Forms reader.

If your data is manual rows in Ninja Tables that you’ve been hand-maintaining, the same migration logic as TablePress applies: build a Gravity Form, import existing rows, swap shortcodes.

From a custom WordPress page template#

The most common “migration” we see: a custom page template that calls GFAPI::get_entries() and renders a hand-rolled HTML table. Replace the entire template with a single shortcode.

Before:

<?php
$entries = GFAPI::get_entries(42, [
  'field_filters' => [['key' => 'created_by', 'value' => get_current_user_id()]],
]);
echo '<table>';
foreach ($entries as $e) {
  echo '<tr>...</tr>';
}
echo '</table>';

After (in any WordPress page or post):

[gravity_table id="42" filter_by_user="true"]

Plus you get sortable headers, pagination, mobile cards, exports, and inline editing for free.

Need help?#

Email info@fahdmurtaza.com with:

• Which plugin you’re migrating from
• A link to your current public-facing page (if applicable)
• A description of how the data flows

We’ve helped several teams migrate from each of the above and can usually share a working shortcode within 24 hours.

Related#

• Quick start, building your first table
• Shortcode reference, every parameter
• /vs comparisons, side-by-side feature matrices