Key Challenges & Context: Fragmented Tools, 9 Teams, and No Single Source of Truth
Our client is a major international management and technology consulting firm with thousands of employees across multiple countries. Their internal IT operations span several support tiers (L1, L2, L3), facilities management, and business unit-specific service teams, nine teams in total, each with their own workflows and processes.
The problem was fragmentation. ITSM ran on Freshservice. Documentation lived in SharePoint. Asset tracking was siloed and manual. Each team had developed its own processes, its own ticket handling habits, and its own way of managing knowledge. Nothing was connected.
The client’s goal was clear: consolidate everything into a single, governed Atlassian Cloud environment. Jira Service Management for ITSM. Jira Assets for IT asset management. Confluence for the knowledge base. One platform, nine teams, unified workflows.
What made this project complex was not the target architecture (which is well-understood) but the starting point:
- Legacy data at scale: 150,000 historical tickets in Freshservice and 4,000 pages in SharePoint needed to migrate with full fidelity: attachments, comments, field mappings, and metadata intact. Losing historical context was not an option for a team handling 1,500 tickets per month.
- Nine teams, nine ways of working: Each team had different request types, escalation paths, SLA expectations, and permission requirements. Standardization had to balance governance with the flexibility each team needed to operate effectively.
- No centralized asset management: IT assets (laptops, people records, infrastructure components) were tracked in spreadsheets and disconnected systems. The client needed a CMDB integrated with their identity provider (Microsoft Entra ID) for automated user synchronization.
- Portal complexity: The customer-facing JSM portal needed to serve internal employees across all nine teams with 30+ request types, role-based visibility, and integrated knowledge base access. Getting permissions wrong would mean either exposing sensitive content or hiding resources people needed.
- Knowledge base governance: Articles needed to serve both agents (internal, technical) and customers (self-service, how-to), with different visibility rules for each audience. Migrating from SharePoint meant restructuring content, not just copying it.
The Approach: Standardized Design, Controlled Migration, and Automation at Scale
We structured the project over 6 months, working in parallel across four workstreams.
Service design and standardization
Before migrating anything, we designed the target operating model. This meant defining standardized Jira Service Management projects for Facilities Management and IT Support, supporting 5+ distinct service workflows.
For each team, we defined:
- Request types and forms (30+ across the portal)
- Routing rules and queue assignments
- SLA configurations with appropriate calendars and escalation triggers
- Role-based visibility rules determining which teams and customers see which request types and KB articles
The design phase ensured that migration had a clear destination, not just a “copy what exists” approach but a structured improvement.
Data migration from Freshservice and SharePoint
Historical ticket migration was handled using Relokia, a specialized migration tool for ITSM platforms. We mapped every field, attachment type, and comment structure between Freshservice and JSM to ensure full data integrity across 150,000 tickets.
For knowledge base content, we migrated 4,000 SharePoint pages into Confluence spaces with preserved structure and permissions. This was not a flat copy. We restructured content into a Confluence information architecture designed for JSM’s Knowledge Base integration, separating internal agent-facing articles from customer-facing self-service content with appropriate access controls.
All migrations were validated in a sandbox environment before production rollout. Each batch went through integrity checks: ticket counts, attachment availability, comment threading, and permission inheritance.
Asset management and identity integration
We configured Jira Assets with a schema covering People, Laptops, and other IT resources. The critical piece was automating imports from Microsoft Entra ID, ensuring that the people directory in Assets stays synchronized with the organization’s identity provider without manual intervention.
This gives the client a living CMDB that updates automatically as employees join, move between teams, or leave the organization. Assets are linked directly to JSM tickets, providing agents with immediate context when handling requests.
For organizations considering how identity management integrates with Atlassian environments, the Entra ID synchronization pattern we implemented here is a common building block.
Automation and operational efficiency
With the structure in place, we implemented 50+ automation rules covering:
- Ticket assignment based on request type and team routing
- SLA triggers with escalation notifications when thresholds approach
- Recurring task creation for scheduled maintenance and compliance activities
- Status-based notifications to customers and agents
- Auto-classification of incoming requests based on form fields
These automations replaced manual triage and routing processes that previously consumed significant agent time across all nine teams.
Benefits: Unified ITSM Platform Serving 500+ Users Across 9 Teams
Six months after project kickoff, the client operates a fully consolidated Atlassian Cloud environment.
Single platform for all IT service operations
- 1,500 tickets/month handled through unified JSM workflows across 9 teams
- 500+ active users (agents and customers) working from a single platform instead of fragmented tools
- 30+ request types organized in a portal with role-based visibility, so each team and customer segment sees only what’s relevant to them
- Standardized templates and processes across all teams, eliminating the “nine teams, nine ways” problem
Integrated asset management
- 10,000+ assets managed in Jira Assets with automated Entra ID synchronization
- Agents see relevant asset information directly in ticket context, eliminating manual lookups
- Asset lifecycle (provisioning, assignment, decommissioning) tracked in a single system with full audit trail
Centralized knowledge base with governed access
- 4,000 pages migrated from SharePoint into structured Confluence spaces
- Knowledge Base integrated with JSM portal, enabling customer self-service and reducing ticket volume for common questions
- Clear separation between internal (agent-only) and external (customer-facing) articles with role-based access control
- Faster onboarding for new agents who can now find runbooks, procedures, and troubleshooting guides in one place
Operational efficiency through automation
- 50+ automation rules handling ticket routing, SLA management, escalations, and notifications
- Reduced manual triage and assignment work across all teams
- Consistent SLA tracking and escalation, replacing ad-hoc follow-ups with systematic triggers
- Improved visibility for management through standardized reporting and audit trails
Smooth transition with zero data loss
- 150,000 historical tickets migrated from Freshservice with full field mapping, attachments, and comments preserved
- Complete migration validated in sandbox before production cutover
- No disruption to ongoing operations during the transition period
Key Takeaway
Consolidating ITSM, knowledge, and asset management into a single platform is not primarily a technical challenge. The technical migration (moving tickets, pages, and assets) is the straightforward part. The real work is in service design: defining how nine teams with different needs will operate on a shared platform without losing the flexibility they need.
The organizations that succeed at this consolidation are the ones that invest in designing the target operating model before migrating data into it. Migration without redesign just replicates fragmentation in a new tool. For organizations evaluating this kind of transformation, a structured assessment of migration complexity is the right starting point.
