Starhive is known as an asset management platform, but at its core is a flexible database that can store any type of object and map any relationship. So we decided to challenge ourselves. Could Starhive handle something as complex and fluid as product development?
The result exceeded expectations. The migration helped our engineers keep the user in mind, and it gave our engineering manager, Olga Ehrenstal, and other stakeholders clearer visibility across teams and product components. It also helped us identify improvements to our ticketing features that shipped within weeks.
Below is a breakdown of why we moved, how we handled the migration, and what we learned.
Olga Ehrenstal is the Engineering Manager at Starhive. Her responsibilities include roadmap planning, compliance puzzles, and collaboration with business teams, as well as managing the team of engineers to ensure they're building a software that users love to spend time in.
Like many development teams, we started tracking our development work in Jira. It worked well but as we grew and multiple development teams formed, we started to run into a few inefficiencies.
Tracking work across teams on the same feature became harder. Tickets were stored in separate boards and views, which made cross-team work difficult to follow and even more challenging to report on. And we were not able to have a company-wide roadmap (rather than per project) without upgrading our Jira plan.
Some stakeholders, who were not so experienced with Jira, struggled to find the information they needed. We also had challenges around bug reporting. Non-developers often logged issues in the wrong project or against the wrong team, leading to delays and lost bugs.
And lastly, the UI. Even seasoned Jira admins at Starhive felt that the Jira UX has not been keeping up with the times and was becoming increasingly difficult to use, especially for non-experts.
These aspects were not huge blockers for us, but it was enough friction for us to start rethinking our setup. We wanted something simpler, yet flexible and powerful.
The migration was not just an attempt to fix everyday frustrations. We also wanted to stretch the limits of Starhive’s architecture. We know Starhive works for tracking maintenance tasks for assets, but could it also serve as a general ticketing system?
We were also keen to start dogfooding Starhive to help our engineers understand the user experience. Something we think is critical to producing a product users love to spend time in.
While we already track our assets, holiday requests, and desk booking in Starhive, these aren’t areas where the majority of our team spend a lot of time. Extending our internal use of Starhive to product development would give them far more insight.
We decided to migrate everything in one go. The goal was to avoid reinventing our entire process. Each team kept their existing workflow, naming, and states to reduce the time taken to adapt to a new system and avoid unnecessary disruption.
Olga started by designing a simple data structure in Starhive, building out Types for epics, tickets, bugs, sprints, and engineering teams. She worked with the engineering teams to understand which Jira fields should be kept, and which weren’t needed. Relationships between Types were added to mimic how Jira links issues together, including parent-child relationships, blockers, and dependencies.
We then imported existing Jira tickets directly into Starhive. Statuses, descriptions, comments, and relationships were imported cleanly with limited manual work required.
The full migration took less than one day of hands-on time. Our high experience with Starhive definitely made this faster, but the process itself is simple enough that teams who spend a little bit of time learning how Starhive works could recreate this quickly.
The impact was immediate. Our engineers spotted quality-of-life improvements within hours. Because they were using Starhive every day, they quickly identified small UI changes and workflow improvements that were easy to ship. Dogfooding led directly to dozens of enhancements that now benefit all our customers.
Stakeholder visibility improved quickly too. Olga (and other stakeholders) can now view progress across teams in one place without switching dashboards or hunting for links. She estimates the new setup saves her at least one hour per week by removing the need to piece information together manually.
Everything is centralised. Since we also manage assets, holiday requests, and desk booking within Starhive, using the same system for product development reduces the amount of switching required.
Starhive is primarily an asset management system with a light ticketing layer. For this project, we expanded that ticketing layer to support product development. It works well for us today and gives us a strong platform to build on.
Next we plan to explore where else Starhive can replace third-party tools. Early candidates include parts of our compliance workflows currently handled in Drata, bringing in data on customer contracts and licenses from Stripe and other sources to get a complete view, our partner relationship management system, and some of our marketing tools. We will also replace Jira for our support ticketing with Starhive.
Every new use case helps centralise our internal operations, remove scattered SaaS tools and data stores, and understand how far Starhive can go as a no-code app builder.