Table Grid Editor is a Jira app that adds an editable table to an issue as a custom field. Teams use it when an issue needs several rows of structured data, such as the line items in a stock delivery order. Development on Table Grid Editor started in 2011, and many of the frameworks it depends on are no longer supported. Its users are moving to Table Grid Next Generation.
That move has 2 legs. On Jira Data Center, the Table Grid Migration Tool (TGMT) converts Table Grid Editor fields into Table Grid Next Generation fields. If you're also moving to Jira Cloud, the Cloud Migration wizard inside Table Grid Next Generation for Data Center copies your grid configuration and data to the Cloud version of the app.
Both legs check your configuration before they write anything to the target. In TGMT, Validate is a separate button from Run. In the Cloud wizard, Step 5 shows how many warnings it found before you start. Neither check changes your data, so you can run them as often as you need. I'm on the Exalate team that builds both migration paths for Table Grid.
Why does Table Grid migration need validation
Table Grid migration doesn't move everything. Some settings can't be represented on the target side, so they stay behind by design.
On the Editor to Next Generation leg, that covers formulas, data sources, dynamic lists using SQL queries, Driving Tables, grid initialization properties, and the Table Grid Reader custom field. Formula results do transfer as data, with the column type matching the result type.
On the Next Generation to Cloud leg, it covers Dynamic Options on Single and Multi Select List columns, attachment columns, formula columns, and large integer values.
Validation shows you where those sit in your own configuration while you can still decide what to do about them.
Leg 1: can this configuration be converted?
TGMT checks whether each Table Grid Editor field's configuration can exist in Next Generation, and lists every element that can't.
In TGMT 4.7 validation runs per field. Each field in a batch gets validated and reported on its own, so a problem in one doesn't stop the others from getting their own result.
Leg 2: do the source and target configurations match?
Step 5 reports the number of warnings before the run starts. Open the list and each mismatch is identified by column name, grid ID, or field context ID, so you can go straight to it.
You can go back and fix each one, or start the run and deal with the mismatches afterward.
What happens when a grid or field fails
On leg 1, each field reports its own outcome. You get a field-by-field result showing what migrated and what didn't, and one failure doesn't mark the rest as failed.
On leg 2, the run completes and reports a count like Migrated Grids: 4/5, with the failed grids listed and a reason for each. Retry continues with the grids that haven't migrated, and you can download the full log.
Which failures won't the Cloud wizard warn you about
Review compares your Data Center grid configuration against your Cloud one. It flags columns that exist on one side but not the other, values that appear in one column but not the other, and general configuration mismatches.
Three issues bypass it: required-field rules, static rows, and unmapped issue types; each requires manual review before migration. The Migration Feature documentation lists each one with its workaround under Known Issues.
What should you check before and after each run
Whichever leg you're running, back up your grid data and rehearse on a sandbox first. During the run, read each warning instead of clicking past it.
On leg 1, validate every field and resolve or accept each finding. Note which formulas you'll rebuild afterward, since formula results transfer as data while the formulas themselves stay behind.
Leg 2 needs more preparation. Make your target columns editable and clear the three failures above before you start, and don't cancel once the run is going, because migrated grids can't be rolled back.
Then, after a leg 2 run: download the log, check the failed grids list, rebuild Dynamic Options and formulas where you need them, and put Required and Cell Can Be Edited back to their original settings.
Validation costs nothing and writes nothing, so there's no good reason to skip it on a first run.
Currently, there is no direct migration path from Table Grid Editor to Table Grid Cloud. If you would like to migrate directly from Table Grid Editor to Table Grid Next Generation on Jira Cloud, please raise a support ticket for assistance: Table Grid Support Portal .
If you've hit something else the validation didn't catch, tell me what it was and I'll take it to the team.
