From DC Plugin to Forge App: The Decisions That Actually Matter

Your vendor apps have a migration path. The plugins you built yourself do not.

Atlassian Data Center is winding down, and that gets plenty of attention for the products. It gets much less for the thing many enterprises quietly run on: the extensions they built in-house. The workflow post-function from 2017. The integration into the internal ERP. The dashboard finance opens every Monday. Nobody migrates those for you. There is a Java codebase, a colleague who may or may not still be with the company, and a deadline.

The good news: Forge is a genuine native home for that code, hosted by Atlassian, with extension points that cover most of what a DC plugin used to do. We covered the timeline and why Forge is the natural successor in the article linked above; this one is about the journey itself. Because the less good news is: porting under deadline without a map is exactly where these projects stall.

We have taken a number of enterprise teams through that path in our Forge developer workshops this year. This article is the map, written not for the developers who attend but for the managers who decide. Because the pattern across every single engagement is the same: the expensive mistakes are decisions, not code. Here are the six that matter.

Decision 1: Who is in the room

The most useful person in one of our discovery sessions had never written a line of code. She knew the old tool inside out: which fields people actually filled in, which reports nobody read, which workaround the team had lived with for years. None of that was in any documentation, and all of it decided what the new app needed to be.

Feasibility is a conversation, not a spec. When only developers are in the room, the conversation drifts to how. The what and the whether, the questions that decide if the project makes sense at all, belong to the people who own the problem: domain experts and decision-makers. Two sentences come up in almost every session, “there is no off-the-shelf tool for this” and “our use case is too specific for any vendor’s roadmap”. Both are real reasons to build, and both are business decisions.

So before anything technical: decide who joins the feasibility conversation. It should not be just the devs.

Decision 2: What you budget time for

Teams arrive thinking they need to learn Forge. They don’t, not first. The Forge API is the well-documented, manageable part. The real jump for a Java-heavy DC team is the world around it: JavaScript instead of Java, an event loop instead of threads, npm instead of Maven, React as the UI model. These are mindset changes, not syntax changes, and strong engineers cross them quickly if someone points out the potholes instead of letting each one be a surprise.

For a manager this is a planning fact: budget the ramp-up for the ecosystem shift, not for “learning an API”. It is days with guidance, weeks without.

Decision 3: Whether IT is involved before day one

The closest we have come to losing a workshop day had nothing to do with programming. It was a corporate network that quietly refused to let the tools talk to the outside world, and the people who could fix it were not in the room.

A hands-on Forge setup does exactly the things corporate networks are built to distrust: install packages from the internet, sign in to cloud services, open a tunnel between a laptop and a development environment. That is not a flaw in your network. It is a flaw in the plan, if the plan was “we’ll sort it out on the day”. We now run a short remote pre-check on the real machines a week or two ahead, and it has saved every first morning since. Whoever runs your enablement should do the same, and your IT and network people need to be in the loop early.

Decision 4: The design calls you will live with

Two teams build the same small Jira app. Same feature, same afternoon, roughly the same amount of code. One team’s users can filter for the data in JQL, report on it, build dashboards. The other team’s data exists only inside a panel, invisible to every search. Nobody wrote worse code. They made a different storage decision, in about ten seconds, on day one.

That is what building on Forge actually is. The documentation lists every module and storage option accurately, but it cannot tell you which one fits your problem, and that choice is the thing you live with. The same is true for whose permissions the app runs with: act as the app where you needed to act as the user, and you have built a quiet data leak that behaves perfectly in every test. None of these calls is hard to implement. All of them are expensive to reverse six months in.

The management takeaway: make sure these decisions are made consciously, with someone in the room who has watched them play out before, and not as ten-second defaults.

Decision 5: What AI changes, and what it does not

We asked an AI builder for a Jira app. It worked on the first try, and the code was genuinely good, better than plenty of hand-written first drafts. The review still found four issues, and they shared one trait: none of them throws an error, every one of them produces a plausible, wrong number. The full review, and the checklist for taking an AI-built Forge app to production, is its own article.

The management point here is the honest 80/20 of AI-assisted Forge development. The 80% arrives astonishingly fast, and with Rovo Agents now a first-class Forge module, AI is not just how you build but something you build in. What does not transfer is the judgement: knowing which questions to ask of something that already looks finished. “No code” is a claim about the interface, not about the expertise. Plan your enablement accordingly: the skill your team needs is shifting from writing code to reviewing and hardening it.

Decision 6: Who owns the app on Monday

Two halves of the same decision. First, operations: “we moved to cloud, so operations is taken care of” is half true. Hosting disappears, and Atlassian runs the platform well. But the app is still yours: it calls APIs that evolve, meets data that stops looking like your test data, consumes resources that past the free tier become an invoice, and its upgrades wait for admin consent, so the installed base quietly spreads across versions. Someone has to open the Developer Console. Decide who, before you ship.

Second, the road after the prototype. Our workshops end with every team having deployed their own working app, and then the real question lands: what happens Monday? We have watched three answers work. Build it yourselves, with expert support on call. Co-build, pair programming on your real first app. Or delegate the build entirely while your team stays close enough to understand it. All three are fine. The one outcome to refuse is the black box: an app nobody in your organization understands is not an asset, it is a liability with a login page.

The map in one paragraph

Get the right people into the feasibility conversation. Budget for the ecosystem jump, not the API. Clear the network before day one. Treat storage, permissions and entry points as decisions, not defaults. Use AI for the 80% and keep the judgement for the 20%. And decide who owns the app on Monday, because the prototype is the start, not the finish.

None of this is hard once you know it exists. The risk is not knowing it exists, with a DC deadline behind you.

We built our Forge developer workshops around exactly this path, from discovery to prototype, including the operations and review modules most trainings skip. If your team is facing the jump: go.seibert.group/forge-training-en