Every software renewal negotiation runs through the same sentence, said matter of factly on both sides of the table: nobody is going to switch off a system in production. The sentence usually proves true. The problem is not the intent of the person saying it, it is that the continuity of your operation has become a decision that has to be made again every year.
This piece closes the series because it answers the question the first one left open, what keeps running if the contract ends. The piece on pricing signed off by saying that the other half of the bill is what happens when the contract ends. This is that half.
The difference between running, updating and being supported
Almost all enterprise software stops working on a date nobody discusses at signature. The service runs on the vendor's infrastructure and keeps running for as long as the invoice is paid. If the renewal does not happen, the system stops, not because anyone decided to punish the client, but because the subscription architecture turned continuity into a function of the calendar. That blurs three things sold as one: continuing to run, continuing to receive updates and continuing to have someone on the other end when something breaks are separate conditions, with separate risks.
In the public sector the distinction is harder: continuity of a service to citizens should not depend on the budget appearing in the next fiscal year. Aptabit's answer to that constraint is contractual. Public sector organizations can acquire the line under perpetual licensing, with a permanent right of use and no annual renewal. Combined with installation on the organization's own infrastructure, the arrangement takes off the table the two levers most often used to hold a client in place, the annual renewal and custody of the data. It does not take the third. Fixes, new versions and someone to answer when something breaks are still contract. It is the predictability argued in the pricing piece carried one step further: a fixed license makes the bill knowable for as long as the contract runs, and a perpetual one removes the expiry date from the right of use, not from maintenance.
What survives without depending on us
Part of the answer is settled before the expiry date, and it does not depend on the vendor. If the answers your operation relies on come from an open model running on your own infrastructure, that model did not arrive with our license and does not leave with it. Our site describes the arrangement: local models served through Ollama, vLLM or LM Studio, swapped whenever you want. The morning after the contract ends, the model is still on the server it was already on, and so is the corpus.
Two earlier pieces meet here, the one that asked whether a local model is good enough for the task and the one that asked where it runs. If a flow points at an external provider's key, the contract that decides the next morning is that provider's, not ours. And the agents, the flows and the permissions the platform adds on top of the model stay subject to the signed license.
Where the perpetual license solves nothing
A perpetual license is not the same thing as a system that lasts forever, and closing the series with praise for our own choice would be the worst possible use of the last piece. The perpetual option is offered to public sector organizations, and a buyer under the ordinary commercial model does not have it. There are at least three things a license does not solve on its own, and the third is the one left for buyers under that model.
Who knows how to run it. Software that keeps running needs people able to operate and troubleshoot it, and a permanent right of use does not create that capability. For an organization with no infrastructure team, a subscription is the coherent model. The question to ask is who operates the system years after go-live, not whether it can still be used.
Security fixes. A right of use is one thing, maintenance is another. What a perpetual contract covers in updates, future versions and support varies, and none of it follows from the word perpetual. An organization that treats a perpetual license as an exemption from maintenance trades one risk for another, and the second shows up later and costs more.
The license itself. The platform comes up in your environment, but it comes up with a signed license, and our own site says there is a grace period. That is a technical lever tied to the contract, the same kind this text criticizes above. What the term and the grace period do at expiry does not follow from the architecture, and it is not published yet. The site says a grace period exists and stops there: the condition lives in the contract. Without it in public, a buyer under the ordinary model cannot check what the first piece promised this one would answer. We are going to publish how long the grace period lasts, what stays executable during it, and what happens to the installation once it ends. Nothing else in this series goes out before that does.
The exit test that belongs before signature
Getting out of a vendor is a property of the project, not a clause in the contract, and it is verified before signing. The question to ask is how the vendor documents the exit, not whether the vendor says an exit exists. The questions below belong in any proposal, whether the answer leads to Aptabit or somewhere else:
- If I stop paying tomorrow, does the system keep running, stop receiving updates, or stop working?
- Where does my data sit the next morning, and do the indexes and the derived representations come out with it?
- Are the flows, the configurations and the permissions I built readable outside the product?
- Does the model that generates the answers stay available to me without this contract?
- How long would it take and how much would it cost to rebuild this operation somewhere else, estimated by the people who would have to do it?
The fifth is the one that usually goes unanswered, and it is the one that sets the real price of the other four.
Why this piece closes the series
The series started from a line on our site, that the data that matters most is exactly the data you can't send, and the decision that line imposes is to go to the data, rather than asking the data to come to us. The earlier pieces walked through where the data sits, whether a local model is enough, where the software runs and who operates it, what the law still requires, and what the bill looks like when it is a license rather than consumption. What is left at the end is the subject of this one. With the database, the files and the vectors inside the client's own environment, termination stops asking where the data is and starts asking what format it is readable in without the product.
None of that makes the system last forever, and that is the inconvenient part of closing the series here. What the architecture takes off the table is custody of the data, part of the problem and not the problem itself. The right to run the software and the maintenance behind it still depend on a contract that someone has to renew or honor. A contract is still a negotiation, here too.