Multi Level Cascade (MLC) fields can now move from Table Grid Editor (TGE) to Table Grid Next Generation (TGNG) on Jira Data Center and Server. Table Grid Migration Tool (TGMT) 4.7 added MLC migration, on that leg only.
I work at Exalate, where we build Table Grid Next Generation and the Migration Tool. MLC migration has been a long-standing request from customers who rely on these fields.
Note that this support applies only to the Editor-to-Next Generation migration, not the Data Center-to-Cloud migration.
How does MLC migration work in TGMT 4.7
Select an eligible MLC field, configure the destination as either a new field or an existing one, validate, then run. Each field gets its own result.
Migrating into an existing TGNG field is fully functional in 4.7. It was present on the UI before that without working.
Validate and Run are separate buttons on purpose. Validation writes nothing and reports which configuration elements won't survive the conversion, so you can fix things at source first. In 4.7 it runs per field, so one field's findings don't hold up the others.
For the MLC field, all levels come across and so does the data source configuration behind each one. Older versions of the Migration Tool carried none of that, which left you the right hierarchy with every dropdown empty.
What should you check before and after the run
Two things apply to any field you migrate on this leg, MLC or not:
- Version pairing is strict: TGMT 4.7 goes with TGNG 6.1.0 and TGE 1.30.31.
- Do a Jira re-index before you start.
For an MLC field specifically, notice how many levels it has and what feeds each one: JIRA SQL, Jira Fields, JQL, external SQL, or REST. Note which levels use placeholders, since those carry a dependency on the level above.
Then run validation and read each finding. For each finding you have 3 options: fix it at source, accept it, or leave that field out of this run.
After migrating, open the field on an issue and select through it once from top to bottom. A cascade can look correct at level 1 and return nothing at level 3, and clicking through catches that faster than reading the config. Also open a few existing issues and confirm their cascade values still match the options at each level.
Formulas are worth a note here too, though they apply to the whole leg rather than to MLC. Formula results transfer as data, with the column type matching the result type, but the formulas themselves don't. Note which ones you'll rebuild before you start.
Do MLC fields migrate to Jira Cloud
MLC migration works on the Table Grid Editor to Next Generation leg only. It does not continue to Table Grid on Jira Cloud.
We have no plan for MLC on the Cloud leg and have not assessed its feasibility. If your route ends on Cloud, plan for your MLC fields to stay on Next Generation Data Center while the rest of your grids move. Build the timeline accordingly.
Both apps are on the Atlassian Marketplace: Table Grid Next Generation.
In the next articles I'll cover how batching works on each leg, what validation checks before it writes, and the two releases that move Table Grid Cloud off Connect.
If you're still on Editor because of MLC, how many levels do your fields use, and how many of them depend on placeholders from the level above?
