The Mindshift from Data Center to Forge: Why the API Isn't the Problem

As you probably know, Atlassian is winding down the Data Center product line, which means the journey now leads to the cloud for Atlassian customers. When it comes to most of your Marketplace apps, you can sit back: the cloud migration is the vendors’ job, and most well-known Jira and Confluence apps are by now available for Atlassian’s cloud products, as our overview on forge-apps.com shows.

There is, however, a second category of app where you can’t just sit back: the custom apps running inside your own company – a workflow post-function from 2017, an integration into the internal ERP, a dashboard finance opens every Monday.

These smaller solutions have to move to the cloud too. The needs and use cases behind them don’t just disappear along with the platform. The deadline is slowly coming into view now, no longer some abstract date in the distant future. So now your Data Center development team has to learn Forge to migrate these custom apps, right?

The perhaps somewhat surprising answer: that’s not really the point, at least not primarily.

The Jump into the Forge World

The Forge API is the well-documented, manageable part. Look it up, and you’ll find every detail on modules, extension points, and storage options laid out in clean descriptions with examples. For a capable team, picking that up shouldn’t be much of a challenge.

Instead, Java-heavy Data Center teams tend to stall somewhere else entirely. The real jump is the world around the Forge API: JavaScript instead of Java, an event loop instead of threads, npm instead of Maven, React as the UI model. Four shifts that look like syntax at first glance, but are actually mindset changes.

From Java to JavaScript

For many Data Center developers, Java isn’t just a programming language, but an ecosystem of familiar patterns, frameworks, and tools. Dependency injection, typing, build processes, and decades of established best practices are simply a given.

In Forge, the same developers suddenly find themselves in a world that thinks differently. JavaScript and TypeScript are powerful, but they follow different conventions. Many problems get solved differently, many libraries behave differently, and some habits from the Java world lead to frustration rather than productivity.

In practice, a team that has been at home in Java has to let go of a number of things it took for granted. Type safety is optional in JavaScript, not built in; TypeScript closes that gap, but only as consistently as a team demands it. The compiler that, in Java, catches entire classes of errors before the code even runs simply isn’t there in the same form. (TypeScript can bring back many of these safety nets, but they aren’t there automatically; they have to be used deliberately.) And the object orientation that many Java codebases are built around is, in JavaScript, more a convention than a core feature of the language.

This isn’t a value judgment, but it holds true: anyone who treats Forge as “Java, but smaller,” reading and writing JavaScript code on Java instincts, ends up fighting the platform instead of working with it.

From Threads to the Event Loop

Even more fundamental is the shift in runtime model.

In classic Data Center applications, you think in terms of requests, threads, and long-lived processes. When a request comes in, a thread takes over the work. If it has to wait on a database or an external service, that thread blocks accordingly.

In Forge, practically everything runs on asynchronous processing. Developers work with promises, async/await, and events. There’s another difference on top of that: Forge functions don’t run as a long-lived process, but as short-lived, stateless invocations. Forge is, as Atlassian itself puts it, a FaaS platform (Function as a Service). Every invocation starts fresh, holds no state between two requests, and has to either reload or fetch from storage anything it needs.

While the concepts are quick to explain, it takes time to truly internalize them. Many typical problems come from unfamiliar ways of thinking around asynchronous code and Forge functions.

The result is code that looks like it works at first glance, but whose behavior actually depends on timing and chance. A missing await usually doesn’t throw an error; it just creates a race condition that stays invisible in nine out of ten test runs. Someone coming from the thread world instinctively looks for a synchronization problem. In the event loop, though, the answer is almost always: an await is missing somewhere, or a promise chain isn’t passed through cleanly.

From Maven to npm

The tooling changes too.

Data Center teams are mostly used to Maven. Dependencies are managed through familiar mechanisms, projects follow established structures, and the build pipeline has looked much the same for years. A Maven team thinks about dependency management when a new package gets added, and rarely otherwise.

In the Forge world, the JavaScript ecosystem dominates via npm, and npm sets a different pace: more, smaller packages, more frequent updates, a lockfile that actually needs reading and understanding, and an ecosystem that ages faster than teams are used to from the Java world.

For teams coming from an enterprise environment, that can feel chaotic at first, and the pace demands discipline. The real challenge is learning to move confidently through a completely different, more fine-grained ecosystem.

From UI Frameworks to React

The culture shift is especially visible when it comes to the user interface. Many Data Center apps are built on server-rendered UIs, Velocity templates, or classic web frameworks. Most of the logic sits on the server; the interface mainly handles presentation.

Modern Forge apps built with Custom UI use React as the de facto standard. (UI Kit, Forge’s own component-based system, runs on an actual React runtime too, but constrained to a fixed set of Atlassian components rather than free-form React.) Here, development teams think in terms of state, components, and data flow. The user interface becomes a self-contained part of the application, not just a layer on top of the backend.

That’s a fundamentally different mental model for how a UI works in the first place. Once a team has internalized it, they build UIs in Forge quickly and cleanly. For teams without frontend experience, though, this tends to be the single biggest learning step in the whole migration.

What This Means for Planning

For managers or team leads scheduling a Forge migration, the concrete planning fact is that the learning curve has to be budgeted for. It’s not about “learning Forge” here, but about going through four parallel mindset shifts, while the team also rebuilds an existing, live app on the side.

With the right guidance, that’s a matter of days; without it, though, it can take weeks before the team moves through the Forge world with any confidence. One key factor is naming the likely pitfalls up front, plainly. Otherwise the team ends up discovering them one by one on its own, and probably walks straight into a few.

When it comes to the transition, the Forge API is the easy part. As mentioned, it’s documented thoroughly and practically. The more important question is: “How do we help our team internalize these new technologies and mental models as quickly as possible?” That process can mainly be shortened through experience.

Does your company run self-built Data Center apps that you’ll need to bring along to the cloud? Then our Forge workshop for development teams is a good place to start, so you can get things done properly before the deadline really starts breathing down your neck.