What it is
When our Remedyforce ticketing platform was retired, the historical record it held still mattered, for reference, for audit, and occasionally for reconstructing why a decision was made years earlier. This application keeps that archive searchable: full-text search across ticket content, attachment retrieval, ticket history, and an audit log recording who searched for and downloaded what.
One thing the dates on this page do not show. The effort to keep this history accessible began around September 2025, well before the application described here existed. What came first was a rewrite of an older desktop tool as a Python web application, worked on intermittently for months with a chat-based assistant. It reached deployment planning and never shipped. The Blazor application described below is the second attempt, and it reached production quickly precisely because the first attempt had already established what the archive actually needed to do.
Why it mattered
Decommissioning a system is straightforward. Decommissioning it without losing its history is not. The usual outcomes are keeping the old platform running indefinitely at real licensing and maintenance cost, or exporting everything to files nobody can practically search. Neither is acceptable when the data has genuine reference value.
I judged that building a purpose-made read-only archive would be cheaper than either, and it had a side benefit: because the archive is read-only by design, it needed none of the complexity that made the original system expensive to maintain.
The technical problems worth describing
An assembly that was present but invisible to the runtime. The application looks up a user’s display name from the corporate directory so the interface shows a real name rather than a login identifier. The original approach threw a file-not-found error, but only when running under the web server’s application pool identity, and the file it claimed was missing was demonstrably present in the deployment folder.
The actual cause was subtler than a missing file. The directory library was referenced only indirectly, through another package that depended on it, and the build treated it as framework-supplied and therefore omitted it from the deployment manifest. The file was on disk; the runtime had no record that it was allowed to load it. The fix was a direct package reference rather than a transitive one, and wrapping the call site in its own error handling, since an assembly load failure happens before any error handling inside the method can run.
Hosting under a virtual directory, done twice. An earlier approach simulated a sub-path using a configuration value plus a manual redirect. When the application was later hosted as a genuine sub-application, that logic double-applied, because the web server’s own module already sets the path correctly. The fix was to delete the manual handling entirely and read the value the server already provides, which works at a site root and under any virtual directory with no per-environment configuration.
Activity logging that cannot break the application. Login, search, and download events are all recorded, but the logging path is deliberately designed to fail silently. An audit trail is valuable; an audit trail that can take down the application it is auditing is not.
The result
The archive runs in production with full-text search across the historical record, parallel loading of ticket detail so pages render quickly, response compression enabled, and an audit trail of access. The original platform is fully retired.
Where it stands
Stable and in maintenance. The most recent work has been documentation reorganization rather than functional change, splitting durable architectural guidance from dated status history so the project’s own reference material stays trustworthy.