Retire the Platform, Keep the History: Build vs Buy for ITSM Archiving
Every team that retires an ITSM platform has one engineer who says they can build the archive themselves. Sometimes they are right. Usually the cost shows up later, in a place the original estimate never looked.
I say this as the engineer who did build one. I spent years inside a service-management platform, left, and built an archive product because I kept watching teams get the build-versus-buy math wrong in the same direction. They priced the build and forgot to price the next ten years of owning it.
The build is the cheap part. That is the trap.
Build vs buy cost over ten years: the DIY archive starts cheaper, then climbs past a purpose-built archive.
The build starts cheaper and stays that way for a while. What it does not stay is finished.
Standing up a first version of an ITSM archive is genuinely not that hard for a competent engineer. Point at the old database, render the records, add a search box. A capable person can demo something in a couple of weeks. That demo is what convinces a team to build, and it is exactly the wrong thing to base the decision on, because the demo is the cheapest moment in the archive’s entire life.
What the demo does not show is the decade after it. An archive is not a project you finish. It is a system you own for as long as the records have to be retained, which for regulated data can be seven years or more. The real question is not “can we build it.” It is “are we prepared to own it until 2033.”
What ownership actually costs
Schema rot. The source platform’s data model was built for a live system. As years pass, the archive has to keep rendering records faithfully even as the original meaning of fields and relationships fades from institutional memory. Someone has to maintain that fidelity. Forever.
Audit defensibility. A homegrown archive has to satisfy the same audit bar as a bought one: whole records, record-level access control, retention enforcement, and provable integrity. We walk through why most DIY approaches miss that bar in why DIY ITSM archives fail audits. Building those guarantees properly is far more work than building the viewer, and it is the part teams skip.
The bus factor. A homegrown archive usually lives in one person’s head. When they leave, the archive becomes a system nobody fully understands and everybody is afraid to touch. That is a risk auditors and security reviewers specifically dislike, and it is invisible right up until it is acute.
Security and access. The archive holds years of sensitive operational data. It needs authentication, authorization, and access logging that hold up to a security review. That is real engineering, and it is ongoing, not one-time.
The build-it-yourself path often keeps the old platform alive anyway
Here is the outcome I see most. A team builds a homegrown archive, then does not fully trust it for audits, so they also keep the old platform running for read access just in case. Now they are paying for both: the maintenance of the thing they built and the license on the thing they were trying to retire. Keeping a sunset platform alive purely to read old data is expensive on its own. A minimum platform license, plus server infrastructure, patching, and the staff time to babysit a system nobody runs on, adds up to a serious recurring bill that climbs the longer it runs. The DIY archive was supposed to replace that bill and instead sits beside it.
That is the quiet failure mode of build-it-yourself. Not that the build fails, but that it never fully replaces what it was meant to, so you carry two costs instead of zero.
The contrast is stark when the buy path works. One education organization of about 32,000 people, moving from Cherwell to Halo, archived more than three million records in a single weekend and retired the old platform’s recurring cost entirely. A homegrown build would still have been in design review that Monday.
Build or buy, side by side
| Build it yourself | Buy a purpose-built archive | |
|---|---|---|
| Time to a working viewer | Weeks | Weeks |
| Ongoing schema maintenance | Yours, forever | Vendor’s |
| Audit defensibility | You must build and prove it | Built in |
| Record-level access control | You must build it | Built in |
| Integrity guarantee | Depends on discipline | Read-only by design |
| If the author leaves | Archive becomes a black box | Unaffected |
| Old platform can be switched off | Often not, in practice | Yes |
When building actually makes sense
I am not going to pretend buying is always right. Build genuinely makes sense when the dataset is small and static, when there is no meaningful audit or regulatory exposure, when you have a durable owner who will still be around in five years, and when the records simply do not matter enough to justify a vendor. If that describes your situation, build it, keep it simple, and do not over-engineer it.
The moment any of those is false, the math tips. Regulated data, a board that might ask, a dataset that is large or deeply linked, or no permanent owner, and the lifecycle cost of owning an archive forever exceeds the cost of buying one that already clears the bar.
What buying gets you
Cortex Archive is the build I would have wanted to inherit instead of maintain. It is the finished version of what the DIY project is trying to become: the whole record, read-only, access-controlled, and provably unaltered, standing on its own without the retired platform underneath it. It supports Cherwell, ServiceNow, Ivanti Neurons, and Jira Data Center. The data stays on your infrastructure, so buying does not mean handing your history to someone else. It means not owning the maintenance of it. Think of it as insurance: probably the cheapest policy the company will buy, and the one that guarantees you can always get back to every record you generated.
Retire the platform. That decision is usually right. Just be honest about who owns the history afterward, for how long, and at what real cost, before you let the weekend-project version of an archive become a ten-year liability.
Frequently Asked Questions
Is it cheaper to build or buy an ITSM archive?
Building looks cheaper because the first version is quick to stand up. Over the full retention period, owning a homegrown archive usually costs more once you account for schema maintenance, audit defensibility, security, and the risk of losing the one person who understood it. The honest comparison is lifecycle cost, not build cost versus license cost.
What makes maintaining a DIY ITSM archive expensive?
The source schema ages while the archive has to keep rendering records faithfully, the archive must meet the same audit bar as a commercial one, it needs security and access controls that pass review, and it typically depends on a single engineer. Each of those is an ongoing cost, not a one-time build expense.
Why do homegrown archives often fail to replace the old platform?
Because teams do not fully trust the DIY archive for audits, so they keep the legacy platform running for read access as a fallback. That leaves them paying both the maintenance of what they built and the license on what they meant to retire, which is more expensive than either option alone.
When does building your own archive make sense?
When the dataset is small and static, there is no significant audit or regulatory exposure, you have a durable owner who will maintain it for years, and the records do not justify a vendor. If all of those hold, a simple homegrown archive can be reasonable.
Does buying an archive mean giving up control of my data?
Not necessarily. A purpose-built archive like Cortex stands up inside your own network and keeps the data on your infrastructure. Buying replaces the maintenance burden, not your control of the records. Nothing has to be handed to a third party.
What should I evaluate in an ITSM archive, build or buy?
Whether it preserves the whole record, enforces retention and record-level access control, guarantees integrity, removes the need to keep the old platform running, and has a clear, durable owner. Those are the criteria that determine whether the archive survives an audit, regardless of who built it.
Related reading
- Why DIY ITSM Archives Fail Audits — the audit bar a build has to clear
- Evaluate the Exit Before the Entry — the criterion that prevents this problem next time
- Cherwell CSV vs. Purpose-Built Archive — why the simplest build loses the record
- Cherwell EOL Dec 2026: What Happens to Your Data — the deadline forcing the decision
Before you build the archive yourself, see the one I built after maintaining the alternative: Cortex Archive keeps your retired platform’s history whole and audit-ready, on your own infrastructure, without the ten-year maintenance bill.