An enterprise migration can move every Jira issue successfully and still leave teams unable to work as they did before.

A saved filter may no longer recognize a ScriptRunner function. A Confluence page may load, but its embedded Jira report might reference an outdated filter ID. A quality-management workflow may appear intact while the integration that validates product information no longer functions.

For organizations with highly customized Atlassian environments, these are not minor technical inconveniences. They can affect reporting, traceability, engineering decisions, and operational continuity.

That was the challenge facing Silicon Labs.

Headquartered in Austin, Texas, Silicon Labs is a leading innovator in low-power wireless connectivity, developing technologies that power connected devices across smart homes, industrial IoT, and other intelligent edge applications.

Behind that innovation is an interconnected ecosystem of engineering teams, business processes, software systems, and organizational knowledge.

Over years of growth, its Atlassian Data Center environment had evolved into a deeply customized platform supporting approximately 3,000 users, more than a million Jira issues, thousands of dashboards and filters, and hundreds of thousands of Confluence pages.

The platform's value extended well beyond the records it stored. Its workflows incorporated business-specific logic. Its reports depended on advanced queries. Its applications supported engineering and quality processes, and its knowledge base contained years of interconnected technical information.

Moving to Atlassian Cloud was therefore not simply a matter of transferring data from one platform to another.

Silicon Labs needed to preserve the intelligence embedded in its existing ecosystem while adapting that ecosystem to an entirely different Cloud architecture.

To address that challenge, Silicon Labs partnered with Empyra, an Atlassian Platinum Solution Partner specializing in complex Cloud migrations, enterprise integrations, software development, and AI-driven innovation.

Traditional migration utilities provide an essential foundation for transferring Jira projects, issues, users, and Confluence content.

But even sophisticated migration tools cannot automatically reproduce every custom integration, application behavior, scripted function, or business dependency built over years of Data Center usage.

Empyra approached the engagement as a broader engineering and modernization program.

The team began with detailed assessments of the existing Atlassian estate, mapping application dependencies, custom workflows, automation rules, identity configurations, reporting components, and third-party integrations.

Every significant capability was evaluated against its business importance and its ability to function in Cloud.

Where native Cloud functionality could satisfy the requirement, Empyra explored replacing legacy customization. Where Marketplace applications offered supported migration paths, the team assessed compatibility and configuration changes. Where critical functionality could not be reproduced through available tools, Empyra designed custom engineering solutions.

This process also required collaboration with application owners, engineering teams, administrators, and business stakeholders to distinguish between what was technically possible and what the organization actually needed.

The guiding principle was simple:

Preserve the business requirement—not necessarily the legacy technology used to deliver it.

That approach became particularly important in the areas where AI-assisted remediation and Cloud-native engineering could provide solutions beyond standard migration tooling.

Jira was only one part of the challenge.

Silicon Labs' Confluence environment contained more than 306,000 pages across 1,894 spaces.

Years of technical documentation and collaboration had created an extensive network of embedded reports, diagrams, templates, cross-space references, and third-party macros.

Moving those pages to Cloud did not automatically guarantee that every embedded component would continue to display or behave correctly.

A Confluence Jira macro, for example, might still reference a Data Center filter ID. Another macro might use a custom field identifier that had changed during migration. A third-party formatting macro might require different parameters or an alternative Cloud application.

Even when the page itself migrated successfully, these dependencies could leave important information missing or inaccessible.

Empyra addressed these problems through a combination of migration mapping, scripting, application-specific remediation, and AI-assisted content analysis.

The AI-assisted macro-remediation approach was designed to inspect Confluence page definitions, recognize unsupported or incompatible macros, identify references requiring translation, and apply approved transformations.

For Jira and Jira Issues macros, the solution used Data Center-to-Cloud mapping information to correct references to filters, fields, and projects.

This enabled remediation to be approached systematically rather than exclusively through manual page-by-page editing.

The team also evaluated broader application compatibility challenges.

For example, Brikit Blueprint Maker supported specialized page and space creation processes in Data Center but lacked a directly equivalent Cloud migration path. Empyra investigated replacement approaches involving native Confluence templates, automation, and custom utilities to preserve the essential business workflow.

The same principle guided work involving HTML content, diagram applications, SQL-based macros, and other specialized Confluence capabilities.

The goal was not merely to preserve the pages. It was to preserve the usefulness of the knowledge and the connections between that knowledge and ongoing work.

Large enterprise migrations can introduce configuration anomalies that are difficult to identify through conventional checks alone.

Fields may be duplicated. Roles, priorities, and resolutions may appear more than once. Legacy HTML content can migrate into fields that no longer support the original formatting.

These issues become especially challenging when moving into an existing Cloud environment containing configuration objects of its own.

Empyra's engineering work included a Forge-based, Rovo-assisted migration-cleanup approach designed to identify and address these anomalies.

The solution architecture combined AI-assisted assessment with controlled remediation capabilities.

Its intended functions included identifying duplicate custom fields, examining legacy HTML in field descriptions and message content, and evaluating duplicate configuration entities for appropriate cleanup.

Where a correction could be defined safely, Forge-based actions provided an implementation path.

This approach reflects an important distinction in enterprise AI adoption.

AI can help interpret complex configurations, detect patterns, and recommend corrections. But changes to production environments still require appropriate safeguards, permissions, and validation.

Empyra's approach emphasized that separation between intelligent analysis and controlled execution.

The broader opportunity was to turn repetitive migration cleanup into a more structured, reusable capability—reducing the dependence on manual investigation while retaining engineering oversight.

Some of the most important migration challenges were not generic Atlassian problems.

They originated in the specialized business processes that Silicon Labs had built around its engineering systems.

A particularly important example was OPSNET, Silicon Labs' internal product-information platform.

OPSNET supported Jira workflows associated with product quality and engineering activities, including Quality Investigation and Corrective and Preventive Action processes.

In the original Data Center implementation, custom scripts communicated with OPSNET to validate product identifiers and retrieve information needed by those workflows.

For example, when a user entered an affected part number, the integration could check that value against product data and return related information used in the issue.

This integration depended on Data Center-specific Groovy scripting, custom field behavior, and access to internal services.

Those capabilities could not be copied directly into Jira Cloud.

Empyra engineered a replacement using Atlassian Forge and API-driven integration patterns.

The Forge solution was designed to retrieve dropdown values from OPSNET, validate user selections, and populate dependent fields using authoritative product information.

The engineering effort involved addressing the differences between server-side scripting and Cloud-hosted application execution, including how integrations access external systems and enforce field-level business rules.

The team also developed a configuration-driven approach to unique issue identifiers.

For selected issue types, Silicon Labs required identifiers that would remain meaningful and stable even if issues moved between projects or their Jira keys changed.

Empyra's Jira Cloud application design supported automatic generation and assignment of unique identifiers based on defined administrative rules.

Together, these solutions demonstrated a different role for custom development in Cloud transformation.

The objective was not to recreate Data Center's architecture. It was to preserve essential business capabilities using a Cloud-native design.

Silicon Labs' production migration began in October 2026 following extensive preparation, testing, and engineering work.

The cutover plan addressed the migration of core data, custom fields, applications, workflows, automation, and related integrations.

A planned 72-hour migration window prioritized essential functionality, with defined post-migration activities for historical data, less frequently used dashboards, certain reporting configurations, and vendor-dependent repairs.

Empyra maintained detailed runbooks covering migration sequencing, reconciliation, application corrections, issue resolution, and business validation.

Rollback planning distinguished between two materially different scenarios: returning to Data Center before business users began working in Cloud, and recovering after new transactions had already been created in Cloud.

That distinction was critical because a full reverse migration after go-live could not be assumed to preserve every record, relationship, or application-managed field.

During production cutover and stabilization, Empyra coordinated closely with Silicon Labs, Atlassian, and third-party vendors to prioritize critical issues, apply corrections, and establish visibility into remaining work.

The effort included filter and reference remediation, application-specific troubleshooting, and further validation of Cloud behavior.

As of October 30, 2026, certain remediation activities and final customer validation remained active.

This was an important part of the engagement's engineering discipline: recognizing that a completed data transfer and a fully accepted operating environment are separate milestones.

Empyra is an Atlassian Platinum Solution Partner with specializations in Cloud Migration, Service Management, Software Development, and Teamwork Foundations.

Combining deep Atlassian expertise with enterprise architecture, custom software engineering, AI and automation, integrations, and managed services, Empyra helps organizations modernize complex environments and maximize the value of their technology investments.

From migration strategy and implementation to Forge application development, Rovo enablement, and continuous optimization, Empyra delivers solutions designed around how organizations work.

Explore what’s possible with Empyra: www.empyra.com