Modernizing for a second century in business with integrations, automations, and hard-won lessons from a 5,200-store rollout.

The learnings in this blog post are based on a discussion with Ace Hardware presented at Atlassian’s Team ’26 conference.

Ace Hardware is a 102-year-old hardware co-op that’s a staple across the US. When they decided to modernize their IT service management, they teamed up with Atlassian ITSM specialized solution partner Stratacom to roll out Jira Service Management across their entire IT operation.

At Atlassian’s recent Team ’26 event, Jeff Nason, a 26-year veteran at Ace Hardware and team lead for production support, and Greg Guertin, Project Architect at Stratacom with 18 years of experience, walked through their full implementation journey. Explore the story behind what they built, how they brought it to life, and the lessons that can help other IT teams modernize with confidence.

A co-op at scale

Ace Hardware was established in 1924, named after the fighter pilots of World War I. It operates on a co-op model — meaning the stores actually own the corporate entity. Every investment, every tool decision, every budget line item has to serve the best interests of all store owners, from chains running more than 300 locations to the individual mom-and-pop shop on the corner.

With the co-op model inevitably comes scale. Ace’s 12,000 corporate employees (excluding store staff) support 5,200 domestic stores across 15 warehouses, a presence in 60 countries with 3,000 international stores, and a distribution network so wide that 75 percent of Americans live within a 15-minute drive of an Ace location.

That means the stakes are high for IT. When ITSM breaks down at a company this size, such as when tickets get lost, tools go dark, or teams can’t see what’s happening across applications and infrastructure, the ripple effects reach thousands of stores and millions of customers. Getting ITSM right isn’t just an internal efficiency play; it’s a business-critical capability that underpins the entire co-op’s ability to operate. That’s what made Ace’s decision to modernize so significant and so carefully considered.

The tipping point: outgrowing email-based ticketing

Ace’s previous ITSM tool was a ticketing system that had been in place for about eight years and was showing its age, actively hindering the team’s ability to do their jobs.

The first pain point was that tickets could only be assigned to someone in a predefined team or department. Since those same fields were used for tracking and reporting, assigning work to anyone outside that rigid structure became cumbersome and inconsistent. Eventually, people stopped using the system altogether — team members would fix issues and send a quick email saying, “Hey Jeff, I took care of this.” This meant resolutions contained no tracking, history, or ability to spot patterns and recurring problems.

Additionally, the tool was installed as a client-side application on every machine, so when users ran large filters, the system slowed down or crashed for everyone logged in simultaneously. With no sandbox environment for testing, the team had to make changes directly in production and roll them back quickly if something broke. Reporting meant exporting filters to Excel and rebuilding the analysis from scratch each time, and because people didn’t consistently fill in required fields, the data rarely yielded reliable insights.

Identifying their needs for now and the future

The search for a replacement was guided by a clear picture of what Ace needed, both in the short term and as the business continued to grow. On the functional side, that meant a system capable of handling end-to-end ITSM, including incidents, problems, service requests, software release tracking, asset management, configuration management, and change management. A Salesforce integration was another key priority since most tickets originated from Ace’s care center. IT was receiving roughly 2,500 incidents per month across all applications escalated from the care center, plus another 2,000 job failure tickets generated by automated systems.

The team also needed a self-service portal that end users would actually want to use, an implementation partner capable of handling real enterprise complexity, and a cost structure that fit the co-op model. Critically, they needed a platform that could scale and evolve with the business over many years, not something they’d outgrow in another eight. Modern API integrations and automation capabilities to eliminate repetitive manual work rounded out the list.

Ace’s approach to implementation

Ace chose to partner with Atlassian ITSM specialized partner, Stratacom, and it made a measurable difference in the outcome. Stratacom brought both the technical depth to design integrations Ace couldn’t have built alone and the implementation methodology to keep a complex, multi-phase rollout on track. Working with Ace as the Project Architect at Stratacom, Greg Guertin’s first principle for every customer engagement sets the tone: don’t recreate your old tool. Your previous system can serve as a reference for understanding business processes, but a new tool should be used for what it does well. Carrying forward past limitations or design decisions defeats the purpose of modernizing.

For Ace, this translated into an iterative approach. The team started by gathering requirements and identifying gaps between out-of-the-box capabilities and actual business needs. Jira Service Management checked all the boxes. Upon starting rollout, they deliberately started with easier features and workflows to get something in front of users quickly, gather real feedback, and build momentum. Time for refinement was explicitly built into the plan.

Standardization was another goal, wherever it made sense. One clear example: Jeff had originally built 35 different forms, one for each team. It quickly became apparent that every form captured the same information except for the team field. Consolidating on a single form meant updates only needed to happen in one place instead of 35. The same logic applied to approvals, where a unified process was built to handle manager, application owner, and director approvals rather than building one-off workflows for every request type.

Connecting the dots with Jira Service Management

Without meeting Ace’s integration requirements, Jira Service Management wouldn’t have made it past the evaluation stage. So the implementation team invested heavily in connecting it to the surrounding ecosystem.

Azure Active Directory and Atlassian Guard pull in user and manager data, enabling automated approval workflows based on organizational hierarchy. Intune runs a nightly scheduled API import that brings hardware and device data into the system. Azure DevOps uses a two-way PowerShell integration for release and problem management, syncing bug status, assignee, last touch date, related project, and QA testing status back to Jira Service Management in real time — eliminating the separate spreadsheets and manual lookups Jeff previously maintained across two systems. IBM Workload Automation creates incidents for job failures across 42,000 daily automated jobs, ensuring nothing slips through unnoticed. SolarWinds creates tickets for hardware warnings (disk space, memory, server offline) through APIs, with an automation that checks whether the alert has cleared on its own, closing transient tickets automatically while still maintaining a record for trend analysis. Planview loads active project status through scheduled jobs, confirming whether deployments are backed by funded, active projects.

Salesforce is the most important integration of them all, and the one that handles nearly all incoming tickets from Ace’s care center. Ace’s care center fields all calls, and IT is only a small slice of that volume. Salesforce runs broad case and store operations while Jira Service Management handles IT incidents. Rather than forcing agents to choose between systems, the team built a two-way webhook that syncs core fields (summary, description, caller/contact, email, and linked IDs) between both platforms. In Salesforce, an Escalate button lets agents pick the team and department (merchandising, ecommerce, and so on) to trigger the push. Once linked, a ticket exists in both tools simultaneously: IT can ask for details in Jira Service Management, and Salesforce sees it instantly. Comments also sync in real time, and when IT closes their ticket, Salesforce follows up with the business partner and closes on their end.

Attachments posed a unique challenge. The team solved it by building a Salesforce widget that displays files as checkboxes once a Jira ID is available. Agents select the files, send them, and the widget emails them directly to the Jira incident. The end result is that the integration feels invisible and many Salesforce users don’t even realize there are two systems at work.

Training, cutover, and phased rollout

Final preparation included five mandatory training sessions and a deliberate two-month overlap period. Rather than attempting a complex migration of open tickets, the team allowed existing tickets to close out in the old system during that window. Anything that couldn’t be resolved in time was manually recreated in Jira Service Management — a pragmatic decision that kept the go-live clean and predictable.

The rollout itself happened in three phases rather than one big-bang launch. Change management went first, incident and request management followed, and release management came two weeks after go-live, allowing in-progress releases to complete in the previous system before the cutover. Shared filters were created for everyone as useful starting points, while individuals were still able to build their own.

Asset and configuration management

Asset data primarily comes from the Intune integration and includes hardware details like location, version, patching status, and ownership. The configuration management database builds on this by linking jobs and services to physical servers, creating a map of downstream impacts that teams can act on in real time.

When a job failure incident comes in, it includes a field showing the affected server and all other services running on it. Selecting that information surfaces all related workloads and dependencies, giving the team a clear picture before they take action. The same logic applies to code deployments and outages. If a server needs to come down, there are no surprises about what else goes with it.

Ace’s 6-step software release process

Ace runs a disciplined, highly-visible release process that balances speed with alignment across shared environments and many teams.

  1. Release cadence and environments: Code moves to QA twice daily, at 9 a.m. and 3 p.m., because all teams share a single QA environment. This time-boxed cadence prevents collisions and gives QA predictable windows to validate changes.
  2. Coordinated production deployments: Production releases happen weekly in a two-hour, cross-team meeting where owners confirm dependencies, sequence changes, and call out downstream impacts before a single change rolls.
  3. Parent release + child change requests: Each release is tracked by a parent ticket with child change requests beneath it, enabling parallel work across teams while preserving centralized visibility.
  4. Automation and consistency: Automations generate a consistent set of linked tasks (peer reviews, approvals, extended access) for every release, reducing handoffs and missed steps.
  5. Smart intake via the portal: Requesters select the target release and technology stack in the portal form; those choices drive routing, ownership, and team-specific filters that surface the right work to the right people.
  6. Governance via integrations: Azure DevOps surfaces bug status, assignee, and QA state directly on the release ticket, while Planview confirms whether the linked project is active and funded, keeping releases aligned to approved work.

What changed after go-live

Once Jira Service Management became part of daily work, the wins were immediate and tangible. Users could see work across Jira Service Management, not just tickets tied to their name or team, and demand grew quickly beyond IT as business partners saw the value and requested access. The role-based portal kept each interface focused: service desk users see only the desk; release teams see only release views.

Cloud hosting ended the old system’s reliability problems. No more machine lockups, no shared-server lag, no crashes when someone ran a big filter. The Azure DevOps integration created a data-driven bug-fix workflow, in which each incident tied to a known bug links to the problem ticket, providing a visible count. No need to open individual incidents or scan comment history.

Greg created core portal automations (about 50–60 lines of logic) that capture form data, route tickets, and pre-populate fields before creation. Other examples include stale-status email reminders, standardized release task generation, and admin-built automations that Ace’s team now builds independently, a sign of self-sufficiency that goes beyond the initial implementation.

Pitfalls to avoid

Jeff and Greg were candid about the bumps they encountered along the way:

  • Mandatory fields matter. If your primary assignment or tracking field isn’t required, tickets will go untracked and get lost. Whatever you use to find and assign work must be enforced.
  • Shared fields have a wide blast radius. If a field is used across multiple forms, changing it in one place affects all of them. Plan carefully before touching anything shared.
  • There’s no undo for forms and automations. Once you make a change, it sticks. You can create a new version and toggle between them, but there’s no simple rollback button, which makes testing even more important.
  • API credentials expire. After a period of time, credentials begin expiring and must be renewed. Document when each key was created, by whom, and set calendar reminders for reauthorization before things break quietly in the background.
  • Dashboard visibility requires licenses or Confluence embedding. Leadership from other departments wanted access to IT dashboards, but without a license, they couldn’t see them. Confluence embeds turned out to be a practical alternative for broader read-only access.

What comes next

With months of structured data now living in Jira Service Management, Greg sees two clear priority areas for Ace’s continued growth. The first is taking advantage of Rovo. Starting AI features from scratch is hard when there’s limited data to work with, but now that Ace has a rich, structured data foundation, AI tooling is increasingly useful for pattern recognition, summarization, and surfacing insights that weren’t visible before. One capability already in development is using AI to surface post-incident reviews from similar past outages. When a severity-1 incident comes in, the goal is to automatically pull up PIRs from comparable situations showing how the issue was resolved previously. Since the fix is often the same or similar, this could meaningfully cut time-to-resolution during critical outages.

The second is a deeper configuration management database. It’s already useful in its current form, but there’s room to strengthen the connections between configuration items, routes, and processes, turning the data Ace is already collecting into even richer operational intelligence.

Connected IT that scales with you

Ace Hardware’s journey shows what’s possible when you move from legacy tools to a modern, integrated service platform. By centralizing IT operations, building integrations that serve both sides of every workflow, and empowering teams to automate the repetitive work, they replaced spreadsheets and email-based ticketing with an innovative, cloud-native solution that delivers real-time visibility and faster outcomes across their 5,200 stores.

The lesson isn’t just about the technology. It’s about starting with clear requirements, choosing an implementation partner who pushes you to do things right rather than settle for the familiar, and building in time to learn and iterate. Small automation wins compound into transformation. See Jira Service Management in action.