# Dropping Connect cutomfields while migrating to Forge

**URL:** <https://community.developer.atlassian.com/t/dropping-connect-cutomfields-while-migrating-to-forge/102328>\
**Category:** Adopting Forge from Connect\
**Created:** [August 26, 2026, 6:54am UTC](https://community.developer.atlassian.com/t/dropping-connect-cutomfields-while-migrating-to-forge/102328 "2026-08-26T06:54:13Z")\
**Posts on this page:** 13\
**Page:** 1

<div class="post-metadata">

**Author:** ![margus.nael](https://sea1.discourse-cdn.com/atlassiandeveloper/user_avatar/community.developer.atlassian.com/margus.nael/32/38409_2.png) [@margus.nael](https://community.developer.atlassian.com/u/margus.nael)\
**Post date:** [August 26, 2026, 6:54am UTC](https://community.developer.atlassian.com/t/dropping-connect-cutomfields-while-migrating-to-forge/102328/1 "2026-08-26T06:54:14Z")

</div>

In our Connect descriptor we have modules jiraIssuFields. e.g.

```auto

        "jiraIssueFields": [
            {
                "key": "fieldname",
                "name": {
                    "value": "Field Name"
                },
                "description": {
                    "value": "Created by App."
                },
                "type": "single_select"
            }

```

These fields are by the system locked in connect and are deleted when user uninstalls the app.  
Now in Forge we do not use anymore fields, thus few questions arise that perhaps Atlassian could answer:

- Can we just forget the entries from manifest if we jump from descriptor to manifest? (data is migrated separately by scheduler and placed into Forge storage thus the fields ill be mainly to keep history).
- What happens then with the app created fields? We’d like not to delete these from the system cause history is there in these fields.
- Or can we somehow make these connect fields unlocked before actual migration?

One option is to migrate these fields by the book, but would like to take as little waste as possible to Forge.

best,

Margus

---

<div class="post-metadata">

**Author:** ![Mihai\_leanzero](https://sea1.discourse-cdn.com/atlassiandeveloper/user_avatar/community.developer.atlassian.com/mihai_leanzero/32/55980_2.png) [@Mihai\_leanzero](https://community.developer.atlassian.com/u/Mihai_leanzero)\
**Post date:** [August 27, 2026, 6:27am UTC](https://community.developer.atlassian.com/t/dropping-connect-cutomfields-while-migrating-to-forge/102328/2 "2026-08-27T06:27:29Z")

</div>

Hi Margus,

You don’t drop them, you rewrite them. Each `jiraIssueFields` entry comes out of `connectModules` and goes back under `modules` as a `jira:customField` with the same key plus `migratedFromConnect: true`. That flag has to be set before you deploy, otherwise Forge can’t map the new entry to the original Connect field and the app “will fail to migrate data from the corresponding Connect issue field”. The field name doesn’t change.

Your example is `single_select`, which costs the most to move. No direct Forge equivalent, so it becomes an `object` field and your app owns the select UI. Two things your customers will see: setting a value used to take a bare option id and now needs `{"id": 5}` at minimum, and `=` doesn’t work on the root field any more, so `customfield_10010 = "Apple"` becomes `customfield_10010.value = "Apple"`. Saved filters using the old form break. A parser expression covers the payload change, the JQL one you can’t hide.

What I couldn’t find written down is your actual question: what happens to the field if you take the module out and put nothing back. It isn’t on the issue field page, the Forge custom field page, or the adopting-forge set. I’d want that confirmed by Atlassian before dropping anything that holds history.

Has anyone had a straight answer on that?

---

<div class="post-metadata">

**Author:** ![Margus\_SoftComply](https://sea1.discourse-cdn.com/atlassiandeveloper/user_avatar/community.developer.atlassian.com/margus_softcomply/32/40399_2.png) [@Margus\_SoftComply](https://community.developer.atlassian.com/u/Margus_SoftComply)\
**Post date:** [August 28, 2026, 6:20am UTC](https://community.developer.atlassian.com/t/dropping-connect-cutomfields-while-migrating-to-forge/102328/3 "2026-08-28T06:20:04Z")

</div>

Im also hoping Atlassian to say something about what will happen before I start testing it in dev. Would not want to waste dev environment if it breaks something really bad.

But all in all I do not need anymore connect custom fields and do not want to add forge customfield into manifest, thus **question to**  **Atlassian** - **what happens with modules** (specifically fields - cause these are not just configuration but also contain user data) **that are just removed from connectModules and not added back to forge modules**.

br,  
Margus

---

<div class="post-metadata">

**Author:** ![margus.nael](https://sea1.discourse-cdn.com/atlassiandeveloper/user_avatar/community.developer.atlassian.com/margus.nael/32/38409_2.png) [@margus.nael](https://community.developer.atlassian.com/u/margus.nael)\
**Post date:** [September 1, 2026, 11:04am UTC](https://community.developer.atlassian.com/t/dropping-connect-cutomfields-while-migrating-to-forge/102328/4 "2026-09-01T11:04:54Z")

</div>

@WendyG @rmassaioli can anybody provide some information about the usecase we have up here?

br,

SoftComply

---

<div class="post-metadata">

**Author:** ![margus.nael](https://sea1.discourse-cdn.com/atlassiandeveloper/user_avatar/community.developer.atlassian.com/margus.nael/32/38409_2.png) [@margus.nael](https://community.developer.atlassian.com/u/margus.nael)\
**Post date:** [September 4, 2026, 5:57am UTC](https://community.developer.atlassian.com/t/dropping-connect-cutomfields-while-migrating-to-forge/102328/5 "2026-09-04T05:57:39Z")

</div>

any updates?

---

<div class="post-metadata">

**Author:** ![Mihai\_leanzero](https://sea1.discourse-cdn.com/atlassiandeveloper/user_avatar/community.developer.atlassian.com/mihai_leanzero/32/55980_2.png) [@Mihai\_leanzero](https://community.developer.atlassian.com/u/Mihai_leanzero)\
**Post date:** [September 9, 2026, 7:18am UTC](https://community.developer.atlassian.com/t/dropping-connect-cutomfields-while-migrating-to-forge/102328/6 "2026-09-09T07:18:27Z")

</div>

Hi @margus.nael,

Still not written down. I went back through the issue-field migration page today and it does not cover removing a module without re-declaring it, and it does not state the uninstall behaviour for app-created fields either. The question to Atlassian stands.

One line on that page matters before testing in dev though. “Once a module is migrated to Forge, it cannot be migrated back to Connect. Doing so is not supported and can result in undefined behaviour.” That is about the forward path rather than about dropping a field, but a migrated dev instance is not cheaply reversible.

Still watching this one.

---

<div class="post-metadata">

**Author:** ![margus.nael](https://sea1.discourse-cdn.com/atlassiandeveloper/user_avatar/community.developer.atlassian.com/margus.nael/32/38409_2.png) [@margus.nael](https://community.developer.atlassian.com/u/margus.nael)\
**Post date:** [September 14, 2026, 8:41am UTC](https://community.developer.atlassian.com/t/dropping-connect-cutomfields-while-migrating-to-forge/102328/7 "2026-09-14T08:41:01Z")

</div>

@PhilShakhovskoy @tpettersen @ScottGangemi @rmassaioli @JoshuaTang @WendyG  
Anybody comments ?!? to undocumented area before we start breaking things and causing lot of unneeded effort for both sides!

Margus

SoftComply

---

<div class="post-metadata">

**Author:** ![Margus\_SoftComply](https://sea1.discourse-cdn.com/atlassiandeveloper/user_avatar/community.developer.atlassian.com/margus_softcomply/32/40399_2.png) [@Margus\_SoftComply](https://community.developer.atlassian.com/u/Margus_SoftComply)\
**Post date:** [September 15, 2026, 7:11am UTC](https://community.developer.atlassian.com/t/dropping-connect-cutomfields-while-migrating-to-forge/102328/8 "2026-09-15T07:11:43Z")

</div>

@PhilShakhovskoy @tpettersen @ScottGangemi @rmassaioli @JoshuaTang @WendyG

anyone? **This topic will automatically close in 10 days. Do I need to send reminder every day or need to escalate it to linkedin? What happed to “all the support you need” for this migration?!?**

---

<div class="post-metadata">

**Author:** ![AaronMorris1](https://sea1.discourse-cdn.com/atlassiandeveloper/user_avatar/community.developer.atlassian.com/aaronmorris1/32/46830_2.png) [@AaronMorris1](https://community.developer.atlassian.com/u/AaronMorris1)\
**Post date:** [September 15, 2026, 1:35pm UTC](https://community.developer.atlassian.com/t/dropping-connect-cutomfields-while-migrating-to-forge/102328/9 "2026-09-15T13:35:55Z")

</div>

Hi Margus,

Have you tried submitting a ticket to [Developer Support](https://developer.atlassian.com/support)?

Obviously, it would have been ideal for Atlassian to answer your question here, where everyone would benefit. But after three weeks without a response, that feels unlikely. An “Ecosystem Support Request” might be more successful. (If you haven’t tried that already.)

---

<div class="post-metadata">

**Author:** ![margus.nael](https://sea1.discourse-cdn.com/atlassiandeveloper/user_avatar/community.developer.atlassian.com/margus.nael/32/38409_2.png) [@margus.nael](https://community.developer.atlassian.com/u/margus.nael)\
**Post date:** [September 16, 2026, 7:54am UTC](https://community.developer.atlassian.com/t/dropping-connect-cutomfields-while-migrating-to-forge/102328/10 "2026-09-16T07:54:31Z")

</div>

Heve not tried that because in documentation it says explicitly contact us here.  
I am not a fan of dev support either, cause usually it takes so much energy to get the actual answer there. First they bounce all the tickets back ten times and you need to switch to caps lock and say same thing 10 times before somebody actually reads it.

---

<div class="post-metadata">

**Author:** ![margus.nael](https://sea1.discourse-cdn.com/atlassiandeveloper/user_avatar/community.developer.atlassian.com/margus.nael/32/38409_2.png) [@margus.nael](https://community.developer.atlassian.com/u/margus.nael)\
**Post date:** [September 18, 2026, 7:05am UTC](https://community.developer.atlassian.com/t/dropping-connect-cutomfields-while-migrating-to-forge/102328/11 "2026-09-18T07:05:59Z")

</div>

anybody? @PhilShakhovskoy @tpettersen @ScottGangemi @rmassaioli @JoshuaTang @WendyG

---

<div class="post-metadata">

**Author:** ![rmassaioli](https://sea1.discourse-cdn.com/atlassiandeveloper/user_avatar/community.developer.atlassian.com/rmassaioli/32/35834_2.png) [@rmassaioli](https://community.developer.atlassian.com/u/rmassaioli)\
**Post date:** [September 20, 2026, 7:40am UTC](https://community.developer.atlassian.com/t/dropping-connect-cutomfields-while-migrating-to-forge/102328/12 "2026-09-20T07:40:53Z")

</div>

The best course of action would be to [raise an ecosystem support ticket for this.](https://developer.atlassian.com/support/)

I will also ask my team to review this thread but they will look for the ticket number. Sonif you could provide it here to connect the dots that would be great.

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/atlassiandeveloper/original/3X/7/8/78672baa5ba80cd9164376457051d0eec038b082.png) [@system](https://community.developer.atlassian.com/u/system)\
**Post date:** [September 25, 2026, 6:55am UTC](https://community.developer.atlassian.com/t/dropping-connect-cutomfields-while-migrating-to-forge/102328/13 "2026-09-25T06:55:06Z")

</div>

This topic was automatically closed after 30 days. New replies are no longer allowed.