It's very hard, for that very reason that more of an organization will depend on it over time, making it harder to extricate from it. But there's a number of things that help.
0. Ownership. Try to manipulate the business to put this project under a part of the org where it's very hard for anyone to have leverage over you, so you can fight back when they try to pressure you to keep it going with no budget or staff. (Can you put it under "finance" or "admin" or "HR"? They won't give a shit about your project and aren't responsible to the tech leadership. Sometimes "IT" is the same.)
1. Money. Assign a fixed budget that runs out after X time. Put yourself in a position that you have no way to ask for more money, so they can't keep trying to stretch your team out with no additional funding. Calculate how much it'll cost the business to try to support it past EOL and put that figure where everyone can see it.
2. Limits. Design in very specific quotas and limits that give very reliable but limited functionality. If somebody wants this to scale 100x, show them how it literally can't. Prevent stakeholders from trying to do more than is possible. If they want fewer limits, tell them to give you money out of their budget to build and staff a single-tenant version of it. They will quickly go away, probably to (poorly) build their own version of it.
3. Disclosure. Tell all stakeholders what this thing can and can't do, that you won't be able to scale, what your SLA is, when this thing will be EOL and that they need to put on their calendars now to work to move off of it in time. Do not tell them the actual EOL date, tell them a date 6 months before the actual cut-off date. Communicate often and via various means in public places, because most people will never read anything they aren't interested in.
4. Stakeholder management. Tightly control who is using your system and what they're using it for. Document the downstream business risk. Make a big stink if somebody starts using your dinky little project with no funding for something mission critical. Remind them of how your limits and budget and SLA and design are all tied together and can't be worked around without redesigning the whole thing.
5. Transition planning. When your system goes away, something needs to take its place. At design phase, incorporate a timeline that includes a large chunk of time just for supporting getting people off the platform. Also plan for how you could offload the entire system onto some other system. Create a document that lists what a new system will need to have, so whoever is tasked with that will not build something that is impossible to transition to. At sunset time, redirect work towards the transition. Have a solid change management plan and get stakeholder sign-off.
6. Rigorously track the value created by this thing, or the value lost by trying to maintain it past its sunset date, and all business risks. Collect hard data. You will need it later to argue to senior leadership why keeping this thing online is a terrible idea.