The roadblock you're running into is there by design, and you're running into it for the correct reasons.
User stories are things the user cares about. That's why it's written from the point of view of the user. If you can't express your task as a user concern, then it likely isn't a user concern, which is likely the case here. As far as the user can see, before and after the technical debt task, the same functionality will be maintained, so the user doesn't care what happens behind the screen.
Technical debt is a developer concern. It's something you care about, but which doesn't really add functionality that the application otherwise wouldn't have.
Note: If your technical debt causes an inability to implement a particular feature, then the resolution of that technical debt is inherently part of that feature/user story, at which point the current question is moot as you already have a valid user story.
User stories, and the enforcement of describing tasks as such, forces the workload to be user oriented, which is where the real business value lies for most companies (functionality/features leads to user happiness, which leads to customer acquisition). In this system, technical upgrades can only exist if they allow for adding additional features/business value.
And this is where the crux of the issue lies: what is the business value of your proposed technical upgrade?
- If it adds functionality that the user wants, that functionality is the user story.
- If it's about maintainability (i.e. future tasks can be implemented faster), the cost and effort spent on this should come from the company investing in itself to simplify its future workload. You should note that the user does not care about that (it's not a feature!). This is not a user story and shouldn't pretend to be one.
- If it's about security, then it falls under the purview of security. This isn't always easily expressed as a user story (e.g. the average user doesn't care about using HTTPS). It can be expressed as such ("as a user I want to securely interact with the application") but it's also possible that this security concern does not come from the users but rather your company (at which point we get back to the company investing it itself from the previous bullet point)
- If it's about performance, then that can be construed as a user story within reason. Users don't care about nanosecond optimizations. Users do care about multi-second performance improvements.
- If it's about modernizing the application's UX, then you've got a clear user story: a nicer look and feel. Whether this counts as business value is contextual; how much is your company (and by extension its customers) interested in aesthetics of their product?
But the biggest bullet point, for which this roadblock was almost explicitly created, is developers doing something for themselves, e.g. wanting to play with the newest toys. While you can argue that there are indirect benefits (developer morale, keeping developers up to date, ...), there is usually no real added business value. If there were, you'd be able to easily express the business value as a user story.
In short, your inability to describe the change in function of its business value (= user story) suggests that there is no added business value. In a user story driven environment, this is the exact scenario that is intentionally being blocked to not waste development resources. Asking how to phrase it as a user story would be telling you how to circumvent the intentional checks and balances that your company chooses to operate under, which is not a good way to approach this.
If you need to circumvent the usual precedings (user stories), you need to talk to the project management about the upgrade and its indirect benefits that are not related to business value.
We use the "As a ... I need to ...so I can ...", as well as Gherkin's "Given > When > Then" acceptance criteria, for our standard stories that are more directly customer focused.
Note that this isn't exclusive to user stories. This format can be used to express developer concerns as well, e.g.
As a developer I need to implement dependency injection so I can lower future debugging efforts by using mocks / unit tests.
If this format is the only requirement, you don't actually need to use user stories for this. But if your company restricts this to user-driven business value, then your technical debt is sadly ignored.
I'm not a fan of companies who don't look at developer concerns and are only interested in user concerns; but as a developer I'm not the one who makes the executive decisions and if that's what the company chooses to do, I can't overrule that.