How eazyBI Handles Data Center to Cloud Migrations

Jānis Vītums, the very first employee of eazyBI, has seen it all – from early server setups to cloud migrations. At eazyBI Community Days, he shared his unique perspective on database migrations. And in true eazyBI fashion, he did it wrapped in a parade of company-branded clothes – each item marking a different era of product evolution.

One eazyBI Behind It All

eazyBI has always maintained the same core functionality across all platforms:

• eazybi.com (launched ~2011)
• eazyBI for Jira Server (2012)
• eazyBI for Jira Cloud (2013, back when it was Atlassian OnDemand)

All versions use the same codebase and core database structure. Whether you're using Jira Data Center, Jira Cloud, Confluence, or any other data source, the engine behind the scenes is always the same. This unified design is what makes migrations not only possible but straightforward.

"Migration doesn’t require transforming your data. You’re just moving it."

Why eazyBI Has Its Own Database

Unlike many Jira apps that store data inside shared Jira tables, eazyBI uses its own dedicated databases. That’s because it needs to manage large volumes of structured analytical data – something standard Jira tables aren't designed for.

This decision proved to be a big win for migration simplicity: since all data and metadata are stored independently, it’s easier to package, move, and restore configurations without relying on Jira internals.

From Full Dumps to Flexible Tools

In the early days, the only migration method was a full database dump and restore. It worked, but there were some limitations:

• Couldn’t migrate between different database types (e.g., PostgreSQL → MySQL)
• Required DBA-level access and knowledge
• Was overkill for many use cases (test environments, sandboxing, etc.)

As the customer base grew, so did the need for something better.

Enter the eazyBI Database Migrator

The eazyBI Database Migrator was developed to address those growing needs. It supports two migration types:

• Direct Database Migration
  Transfers data directly from the source to the target database. This method is faster for large migrations but requires both systems to be accessible, with proper drivers installed and connectivity between them configured.
• File-Based Migration
  Packages the migration into a standalone ZIP file that contains all the necessary metadata. This ZIP can be moved and imported into any compatible environment, making it ideal for cases where direct access isn’t possible or environments are isolated.

Behind the scenes, however, both approaches work the same way. Even the direct database method first generates the same ZIP export file internally and then immediately imports it into the target system—making the core logic of both migration types essentially identical.

What Actually Gets Migrated?

One key point was made very clear: no actual data (like issue data or cube values) is migrated.

Instead, the migrator handles:

• Metadata (users, accounts, import configurations)
• Cube structures (dimensions, calculated members)
• Report and dashboard definitions

Because eazyBI imports are repeatable, once the definitions are migrated, you simply re-run the imports on the target system, and you’re back in business.

Data Center to Cloud Migration

Cloud migration follows the same core process: export from the Data Center, import into the Cloud. But the challenge lies in matching Jira data – because internal IDs often differ between Jira Data Center and Jira Cloud.

But here's where it gets tricky – Jira’s internal IDs often change between environments, and that’s where careful handling is needed.

What eazyBI handles:

• Re-creates metadata and definitions (accounts, imports, reports, dashboards) on the Cloud
• Uses name-based matching (instead of IDs) to link projects, users, and custom fields across environments
• Handles most of the matching logic for custom fields, including those used in import definitions, reports, advanced settings, and JavaScript code

What you need to watch out for:

• Gadgets and hardcoded links will break
  Since internal IDs and domain names change in the Cloud, some Jira dashboard gadgets or direct report links may stop working.
• Some reports may require tweaking
  Especially if they depend on fields or values that don’t match exactly or weren’t reconnected properly during import.
• Testing is essential
  To catch any mismatches or broken reports early, run a full test migration before going live. Compare report outputs, re-run imports, and validate data sources.

Cloud to Cloud Migration

As more teams move to Jira Cloud, the need for sandbox environments has grown. That’s where cloud-to-cloud migrations come in.

Use them when:

• You need to test changes before applying them to production
• You want to clone setups between environments

Limitations:

• Jira gadgets must be re-added manually
• Cross-cloud type migrations (e.g., Atlassian Gov → Atlassian Commercial Cloud) aren’t supported

So, Should You Fear Migration?

"The whole point of my talk was to show that migration doesn’t have to be scary.”

Once you understand how eazyBI migrations work – what gets moved, what doesn’t, what might break – you gain confidence and control.

There’s no single definition of success. Sometimes, it’s just about making sure the most important reports still run. Or that your imports work reliably. Or that you no longer need to wake up because your on-prem database ran out of disk space.

Whatever your reason, the eazyBI team is ready to support you.

The Most Important Take-Away

Test your migration before running it in production.
Compare reports. Re-run imports. Check the details.
The better you understand your setup, the smoother your transition will be.

As Jānis joked during his presentation, eazyBI is starting to feel more like a clothing company. Check out the presentation recording and see why and how it all connects to database migrations.