Software stopped being a product and became a service

Boxed software was sold through a physical chain: publisher, distributor, retailer and buyer. That chain gave the product a visible boundary and made a release date feel like the end of the job. The old commercial boundary was tangible. It was a release, a licence key and often a physical object, so it was easy to imagine that the transaction had finished the relationship. The modern service exposes the continuing part: operating the product, changing it, securing it and keeping the account useful. That is more than a different payment schedule. It changes which party must act when the technology, the user base or the threat environment changes.

The retail box made software feel finished

Discs, manuals and shelf space imposed real costs and made inventory planning part of software publishing. A program had to be complete enough to travel, install and remain useful without an immediate connection to its maker. Release timing followed the constraints of delivery. A vendor had to decide what was ready enough to ship and what could wait for a later version. Network channels weakened that discipline by making corrections, trials and plan changes available without a new retail run. The supplier could act more quickly, but customers also gained a product that could change underneath established routines.

The boxed transaction concentrated revenue around launch and upgrade cycles. Vendors had to persuade customers that the next version justified another purchase, often by grouping many changes into a headline release. Revenue recognition reflects a delivery promise over time. That makes retention, expansion and support quality part of the supplier’s financial model, not merely after-sales concerns. It can fund steady product work and service operation, but it can also create pressure to raise switching costs. Buyers should distinguish a product that earns renewal from one that merely makes exit difficult.

Once users installed the program, the supplier often had limited insight into failures, feature use or local configuration. Support depended heavily on what the customer could describe and reproduce. Software selection has become a question of operational design. The tool may be one component among accounts, permissions, databases, integrations and support processes. A useful inventory records each dependency before it becomes invisible through familiarity.

That limited visibility protected local autonomy but also made version fragmentation expensive. A support team could face many combinations of operating systems, patches, plug-ins and custom settings. The customer still carries important responsibilities. A provider can operate infrastructure, but it cannot decide which employees should retain access, which data may be shared or what level of interruption the business can tolerate. Governance remains necessary, although its focus changes from installations to service oversight.

Test the operational claim directly. Migration deserves attention even when no change is planned. The customer does not need a complete replacement project on day one, but it should know whether data can be extracted, whether audit records and attachments travel with it, and which custom processes would need rebuilding. This knowledge improves negotiating leverage and makes a future change less traumatic. It also disciplines the design of the current implementation by discouraging undocumented shortcuts.

Context determines whether the trade works. Support quality often separates a service relationship from a simple licence. The customer needs to know who can open a case, what information will be available during an incident, which response commitments apply and how escalation works. A low-cost plan with no realistic support route may be appropriate for a low-consequence tool and wholly unsuitable for a service that holds critical records.

Practical diligence is modest but specific. Test one important workflow, inspect the administrator controls, read the change-notice process and ask for a realistic export example. A buyer does not need to predict every future event. It does need enough evidence to know where the service boundary sits and who will act when a problem crosses it. That preparation is cheaper before adoption than during a forced migration.

Buyers should separate the nostalgic idea of possession from the actual operating benefits of a local, version-defined tool. The question is whether the task requires independence from a hosted service. A strong decision starts with the exit as well as the start. When teams understand cost, control, data and recovery before adoption, they are better able to use a service confidently and to challenge a supplier when terms no longer fit.

Price, access and data should be reviewed together. Separating them into different meetings often hides the trade-offs that make a subscription attractive or risky.

Clear records keep technical, commercial and business assumptions connected.

Perpetual licences carried recurring work

A perpetual licence looked like a one-time purchase, yet the work surrounding it never became permanent. Patches, support, compatibility testing and upgrades carried costs after the invoice was paid. Software stopped being judged only at the point of sale. A package once implied a relatively stable thing that a buyer could install and keep. Subscription delivery foregrounds the work that continues after purchase: access management, service operation, updates, support and retention of customer material. The commercial model matters because those duties do not disappear; they are reassigned, priced and governed in different ways.

The licence commonly granted a right to use a particular version; it did not promise unlimited future engineering. Vendors already sold maintenance and support contracts, so recurring economics existed before SaaS became widespread. The old release cycle was partly a logistics problem. Media, manuals, stock and channel relationships placed a premium on a version that could stand still for a while. Online delivery shifted the emphasis from manufacturing to version management, service availability and the design of a direct customer channel.

Large organisations often delayed upgrades to avoid testing effort and disruption. Vendors therefore had to balance feature ambition against the risk that customers would remain on older releases for years. The financial model values relationships that persist. That can turn attention toward onboarding, prevention of incidents and practical customer success. It can also turn attention toward metrics that look healthy while hiding dissatisfied but trapped customers. Contracts, exports and support quality reveal which version a supplier is pursuing.

Local deployment gave customers more control over timing, but it also placed responsibility for deployment, backup, security and skilled administration inside the organisation. The running system is now the unit of analysis. A product that appears simple at the user level may connect to identity services, stored records, automations and administrative roles. Those links create value, but they also create consequences if a provider outage, account issue or contract termination interrupts access.

Version fragmentation could preserve stability, but it made it harder to deliver a universal fix or retire unsafe components. The older model distributed operational effort across every customer. The risk is usually in the boundary between provider and customer. Security, resilience and cost control depend on both parties performing their respective tasks. A contract that is vague about that boundary invites failure at the moment a decision is most urgent.

Check the service at its edges. The long-term value of any software model is measured in recoverability. Can the organisation continue essential work during an outage? Can it understand the effect of an update? Can it obtain what it needs if the contract ends? These are not dramatic hypotheticals. They are ordinary management questions for services that hold valuable information and shape routine decisions. Clear answers make adoption safer and renewal more rational.

The operating detail decides the outcome. Ultimately, the useful discipline is to make assumptions testable. Record the expected users, the expected data, the expected workflow and the expected cost; then review them against actual use. This turns a subscription from an automatic recurring expense into an operating choice that can be improved, reduced, replaced or renewed with evidence.

Contracts should not be read only by procurement staff. The people responsible for security, records, finance and the business process should each test the terms that affect them. A good supplier relationship allows these questions to be answered plainly. It does not rely on the buyer discovering a limitation after data and users have become deeply embedded. Shared understanding is a form of resilience.

Evaluate a perpetual option by counting the internal labour it requires, not merely the licence price. Control is useful only when the organisation can exercise it. Use the commercial model as a design choice. A service can be the better answer where common operation and current access solve a real problem. A perpetual or self-managed option can be the better answer where stability, local authority or offline continuity dominate. The sound choice is the one whose trade-offs are explicit.

Before rollout, establish who approves new integrations, who reviews privileged accounts and who owns renewal evidence. These small controls protect against a common failure: a service spreading through normal work until no one can explain its commercial, security or continuity assumptions.

Document the assumption that makes the model attractive, then review it against actual usage. That turns a sales promise into an operating hypothesis that the responsible team can test.

Test one important assumption before it becomes an expensive surprise.

Downloads broke the physical release cycle

Internet delivery made the package less central. Software could be obtained, activated and updated through the network, while documentation and pricing could change without a new manufacturing run. The decisive change was in the relationship, not in the checkout page. A boxed purchase put emphasis on possession of a copy and a defined version. A subscription brings a continuing promise of access to a service that the supplier operates. The buyer therefore needs to consider the service’s behaviour over time, including its release cadence, account controls, data handling and path out.

Direct download removed much of the retail layer and gave vendors a closer link to users. It also created a new dependency on accounts, activation servers and digital payment systems. Physical media made software feel more self-contained than it usually was. Updates, support and compatibility still existed, but they were less visible in the commercial story. Direct digital delivery brought those activities closer to the product and made them available on a much shorter cycle.

Small releases became practical because the supplier no longer had to wait for a disc, a store display or a yearly marketing moment. That shortened feedback loops between a reported problem and an altered product. Recurring income changes the decisions inside a software company. Product teams, account teams and finance functions all gain reason to care about the life of the relationship. That can produce better service. It can also produce excessive tiering, opaque bundles and a habit of treating cancellation friction as a commercial asset.

Download channels made trials, freemium access and self-service purchase possible. Product design and onboarding began to perform work once handled by packaging, resellers and sales staff. The operational dependency is usually broader than the visible feature set. A customer may be choosing an account structure, a storage location, a logging model and a chain of integrations as well as an interface. Before adoption, teams should identify what work stops if access fails, which data becomes unavailable and which internal controls rely on the service.

Direct delivery created new failure points as well. An inaccessible account, changed verification rule or withdrawn installer could frustrate a lawful user even when the code still worked. A good service relationship makes its limits visible. It explains what is managed centrally, what the customer must configure, how change is communicated and what happens in an incident. Hidden assumptions are more dangerous than imperfect technology.

Evidence beats a feature-list promise. Pricing deserves the same scrutiny as architecture. The buyer should identify the unit that causes a bill to rise, the person who monitors that unit, and the action available when usage moves beyond plan. This is especially important for services that price storage, transactions or advanced computing. A price model can be sensible and still become risky when its measurement is invisible to the people responsible for the budget.

A clean contract needs usable practice. An implementation plan should preserve an independent record of important decisions. Keep copies of configuration choices, integration mappings, user roles, data categories and contract commitments in places the supplier does not control. This does not create independence from the service, but it makes the customer less dependent on memory and more able to assess a problem or a future transition.

Service providers benefit from the same clarity. They can state which functions they operate, which customer responsibilities remain, which limits apply and how a customer can prepare for change. Clear boundaries reduce support disputes and help customers see the continuing value of the service. Ambiguity may accelerate a sale, but it weakens renewal confidence and makes every incident harder to resolve.

Ask whether a network-delivered product can still be installed, recovered and used under realistic disruption. The answer reveals how much control has moved from the device to the supplier. The next renewal should never be the first serious review. Sound selection creates a record of assumptions, owners and export needs at the start. That record makes the later decision calmer, more factual and less vulnerable to pressure.

Do not confuse faster deployment with lower complexity. The complexity may simply move into identity configuration, data ownership, user training and supplier management. A short implementation can still create a long relationship, which is why the design choices deserve a durable written record.

One clear owner, one current system record and one scheduled renewal review will prevent many avoidable surprises. The aim is informed control, not procedural theatre.

Test one important assumption before it becomes an expensive surprise.

Cloud operation changed the product boundary

Cloud computing made it possible to run software as a centrally operated service rather than a copy installed and maintained separately by every customer. NIST describes cloud computing in terms of on-demand network access to pooled configurable resources. A software purchase is now often a live operating arrangement. The shift is visible in recurring invoices, but the deeper change is technical and organisational. Code, data, identity, support and release management are joined together in a service that must keep functioning after the original procurement decision. The question for buyers is not just what feature is present today, but which obligations persist tomorrow.

Central operation combines application code with databases, storage, monitoring, traffic handling, backup routines and identity services. The user sees a browser or app; the provider runs the production system behind it. The delivery channel influenced the product itself. Packaging, distribution and installation requirements encouraged large, visible releases. Once the network became the normal path, a supplier could publish smaller changes, revise documentation and serve a user directly. Faster delivery is useful only when customers can see what changed and prepare where preparation is needed.

That arrangement permits a vendor to update server-side software once for many customers, measure performance across the service and provision resources without each customer buying equipment. The supplier’s success became tied to continued use. A major subscription business cannot rely solely on a launch peak; it has to maintain a service customers regard as worth renewing. The healthier version of that incentive rewards reliability, adoption and clear support. The darker version uses complex packaging or hard-to-move data to delay cancellation.

The benefit is not magic. Centralisation transfers operating work to a provider and changes the scope of outages. A local fault may affect one device; a cloud incident can affect many organisations at once. A subscription service carries a hidden map of dependencies. It includes people, permissions, data, vendors and automated processes. Making that map explicit before rollout is a practical way to reduce surprise later.

Customers retain crucial duties around identity, configuration, data classification and business continuity. A hosted product does not remove responsibility for the way it is used. The benefits are real, but the risks have moved rather than vanished. Central release management can reduce local patching while increasing reliance on the supplier’s judgment and availability. Flexible pricing can make a service accessible while making long-term cost harder to see. The buyer needs evidence, not a broad promise of convenience.

Make the hidden dependencies visible. Useful comparisons look beyond feature lists. Two tools may both claim collaboration, security or automation, while assigning very different responsibilities for permissions, storage, integration recovery and support. The buyer should write down the precise workflow that matters, then test each candidate against it. A tool that wins a broad feature comparison can still lose when measured against the one process that must remain reliable during absence, growth or disruption.

Independence is measured in recovery. The right level of customisation deserves restraint. A service may offer scripting, low-code workflows and extensive integrations, but every local adaptation creates a maintenance burden and can raise the future cost of switching. Customisation should be reserved for work that genuinely distinguishes the organisation or meets a real control need, not for recreating every historical preference.

Good governance starts with a basic distinction between reversible and hard-to-reverse choices. A plan tier or seat count can often be changed. A platform that holds records, automations and working habits cannot. Put more research into the decision that is difficult to unwind, and retain enough internal knowledge to challenge a renewal rather than simply accepting the default path. That is a commercial discipline as well as a technical one.

Use the cloud model where shared operation reduces genuine internal burden, but retain clear boundaries for data, access and recovery. The practical test is whether responsibility is visible and manageable. A contract is not a substitute for an operating plan, and a perpetual licence is not a substitute for maintenance capability. Match the model to the work rather than forcing the work into a fashionable pricing structure.

Ask for evidence at the point where the customer needs it: an export demonstration, an administrative walkthrough, a sample notification or an account-recovery test. Broad assurances are not enough.

Price, access and data should be reviewed together. Separating them into different meetings often hides the trade-offs that make a subscription attractive or risky.

Test one important assumption before it becomes an expensive surprise.

Renewals placed retention at the centre

Subscription selling changed a vendor’s calendar. Instead of waiting for a major release to generate new revenue, the company must keep existing customers willing to renew and, in many cases, expand. The box concealed the amount of ongoing work behind a single sale. The service model makes that work visible because someone must operate the environment, handle new risks, respond to customer needs and keep the product compatible with the world around it. A good analysis tracks where those tasks move, who pays for them and what happens when the supplier changes course.

A subscription supplier receives revenue over the service period rather than solely when it ships a copy. This makes customer retention, adoption and service quality commercial concerns as well as product concerns. What looked like a product calendar was also a distribution calendar. Once that calendar loosened, product teams could respond more quickly to failures and customer signals. They could also change more often than customers expected. That is why operational notice and release documentation became more valuable, not less.

Salesforce reported that subscription and support revenues represented about 94% of fiscal 2025 total revenue, while term software licences represented a small share of subscription and support revenue. That filing illustrates the degree to which recurring delivery dominates a major enterprise software model. The invoice is now an ongoing referendum on the product. Customers may renew because the service works, because their organisation is deeply integrated or because leaving feels too costly. These motives should not be conflated. A strong buyer asks whether the provider’s commercial model gives it reason to improve the service or merely reason to make the service sticky.

Retention can encourage genuine care: better onboarding, documentation, reliability and support reduce the chance that a customer leaves. It can also encourage pricing complexity and product bundles designed to raise switching costs. The account has become as important as the installed code. A buyer should examine administration, recovery, records and integration ownership alongside the user experience. Those details decide whether the service remains usable under pressure.

Renewal pressure is not automatically a virtue. A provider can retain accounts because users are happy, because data is hard to move, or because contracts are difficult to unwind. These are not equivalent forms of loyalty. The customer still carries important responsibilities. A provider can operate infrastructure, but it cannot decide which employees should retain access, which data may be shared or what level of interruption the business can tolerate. Governance remains necessary, although its focus changes from installations to service oversight.

Test the workflow under pressure. Different stakeholders see different costs. Finance sees committed and variable spend. Security sees identity, logging and incident exposure. Legal sees terms, processing and responsibility. Users see whether the work is easier or harder. A decision that ignores one of these views often creates a later conflict. The purpose of cross-functional review is not to slow every purchase; it is to identify the dependencies that deserve a deliberate owner.

Cost depends on the whole system. History gives the comparison some humility. Maintenance agreements, hosted applications and time-limited rights existed before the current SaaS market. The newer model became dominant where broadband, web standards, cloud infrastructure and account-based delivery made the continuous service easier to operate and easier to sell. The relevant change is cumulative: technology, finance and user expectations reinforced one another.

Customer control does not require total technical ownership. It requires enough information and ability to make informed choices: who can access the service, what data can leave it, what changes are planned, what the bill measures and what happens at termination. Those are ordinary requirements for a dependable operating relationship. They become especially important when the service supports revenue, compliance or core records.

Judge a subscription by the evidence of earned retention: clear value, clear terms, usable export and support that remains present after the sale. The decision should be made before dependence accumulates. The appropriate model follows the workload, the organisation’s capacity to operate technology and the consequences of interruption. A recurring service is valuable when its continuous work is real and visible. A local licence remains defensible when independence and timing control matter more.

Supplier choices become customer risks when they affect access, price, security or compatibility. That is why a vendor’s change process belongs in due diligence. The customer needs advance information and a realistic way to assess material consequences before routine work is disrupted.

Keep the service boundary visible to the people who depend on it.

Price moved from capital purchase to operating commitment

Subscriptions changed the moment at which software feels affordable. A monthly or annual amount can lower the initial barrier, especially for a small team that cannot justify a large up-front licence. The market moved from discrete releases to continuing obligations. A customer no longer evaluates only a copy of the code; it evaluates a provider’s ability to deliver access, protect information, support users and manage change. That matters because the practical cost of a bad supplier decision usually appears long after a contract has been signed.

The same structure turns software into an operating commitment. Seats, storage, premium support, feature add-ons and consumption charges can accumulate after the original purchasing decision has faded from attention. Retail supply chains made revision slow by design. When software became network-delivered, the economics of a small fix changed. A vendor could issue it quickly, observe its effects and adjust again. That capacity is valuable, but it puts more importance on responsible control of the release process.

Usage-based billing goes further by making activity a variable cost. API calls, compute, stored data or AI requests may be priced separately, which links product design and customer behaviour directly to spend. Commercial attention moved from the next upgrade to the next renewal. Vendors now have reason to measure whether customers remain active, grow their use and receive enough value to continue. Those measures can improve product discipline, but they are not proof of customer benefit. A renewal driven by genuine utility is different from one driven by accumulated dependence.

A subscription can make budgeting more predictable when usage and contractual commitments are stable. It becomes less predictable when the unit of billing is poorly understood or when the vendor can change packaging without practical alternatives. A modern product is often an information system rather than a standalone program. Its operational value comes from connections that are easy to overlook during a feature demonstration. The right diligence asks where data travels, which identities govern it and which workflows would fail at short notice.

Unused seats are the subscription version of shelfware. The waste is often quieter because it arrives through a series of routine invoices rather than a visible, one-time procurement project. The risk is usually in the boundary between provider and customer. Security, resilience and cost control depend on both parties performing their respective tasks. A contract that is vague about that boundary invites failure at the moment a decision is most urgent.

Ask who carries each responsibility. Service quality is often most visible at the edge cases. A normal login, normal invoice and normal update reveal little. A departing employee, a contested bill, an integration failure or a request for a complete export reveals much more. Organisations should treat these moments as tests of the vendor relationship. The result should inform renewal decisions and internal controls, not disappear into one support ticket or one person’s memory.

Controls matter after deployment too. Where services contain personal or confidential information, data handling needs more than a generic assurance. The customer should know the relevant processing roles, retention choices, regional commitments, subcontracting arrangements and administrative controls. The exact legal analysis depends on jurisdiction and context, but the operational need for clear answers exists in every serious deployment.

Before a decision is locked in, create a short operating record. Name the business owner, the technical owner, the data involved, the identity route, the important integrations, the renewal date and the extraction route. None of this is bureaucratic decoration. It is the evidence needed to decide later whether the service still matches the work. A provider that welcomes those questions is more likely to be prepared for a mature relationship.

Calculate the realistic multi-year commitment, including administration and exit work. The small starting price is only one number in the decision. Choose deliberate dependence over accidental lock-in. Every important system depends on somebody. The goal is to make the dependency proportionate to the value received, clear in contract and technical design, and recoverable if circumstances change.

Operational maturity appears in ordinary moments: a new employee joins, a customer asks for information, a password is lost, a budget is reduced or an integration is changed. A software model deserves confidence when those moments are understood rather than improvised.

Document the assumption that makes the model attractive, then review it against actual usage. That turns a sales promise into an operating hypothesis that the responsible team can test.

Name the owner before a routine tool becomes a critical dependency.

Continuous updates rewrote change control

With a running service, updates stop being occasional extras and become part of the promise. Security corrections, browser support and small feature changes can reach users without a separate installation project. The commercial label hides an architectural decision. A perpetual licence and a subscription distribute control, operating work and financial exposure differently. The former tends to make a version durable on the customer side; the latter tends to make a service current on the provider side. Neither arrangement is automatically superior, because the workload and the customer’s capacity to govern it remain decisive.

That pace benefits customers who need current protection or compatibility. It can harm teams whose workflows, training materials, integrations or regulatory controls depend on predictable behaviour. Distribution used to impose a hard rhythm on development. A release was expensive to manufacture and support, so feature groups often travelled together. Internet delivery reduced the cost of frequent revision and gave companies a route around retail intermediaries. It also made the supplier’s account system and service continuity part of the customer’s daily experience.

Central operation reduces the number of versions a provider must support, but it also narrows the customer’s ability to remain on an older release. This is a trade between provider-managed consistency and local timing control. Recurring revenue makes continuity commercially visible. The vendor must plan for service delivery across the term, while the customer must plan for repeated payment and renewal. The advantage is a closer alignment between use and payment; the risk is a closer alignment between dependence and pricing power.

Responsible service operation makes changes visible: release notes, advance notices, deprecation schedules, test environments and clear descriptions of material effects. The details matter most for critical workflows. The software cannot be separated cleanly from its surrounding service. Access rules, data retention, integrations and support routes determine what users can actually do. They also determine how a problem spreads when something changes or fails.

CISA’s procurement-oriented guidance asks customers to demand more secure products and services. In a SaaS setting, that includes evidence about security practice, logging and the provider’s ability to communicate significant changes. A good service relationship makes its limits visible. It explains what is managed centrally, what the customer must configure, how change is communicated and what happens in an incident. Hidden assumptions are more dangerous than imperfect technology.

Write down the real failure path. Evidence should be sought at the level of daily work. A service page or sales presentation is not enough when the product will hold records or coordinate a critical process. Ask to see the administrative view, the export function, the permission model and the process for reporting a fault. These details show whether the provider treats the customer as a partner in operations or as a passive user of an opaque system. They also reveal which skills the customer must retain.

Exit quality reveals real bargaining power. Metrics should be chosen carefully. Active seats, completed tasks, incident volume, time spent on manual work, support requests and export tests can all show whether a service is earning its cost. A dashboard of vanity usage figures is less helpful than a small set of measures tied to the business process the software was bought to improve.

An organisation should review the service at moments that reveal its true character: a material update, an incident, a price change, a major integration or an approaching renewal. These events create useful evidence about documentation, support, notice and recovery. They also reveal whether the supplier’s promises match the way the service behaves under pressure. A decision record prevents those lessons from being lost between teams.

Adopt a light but real change-review process for every critical service. Automatic delivery should not mean unexamined delivery. The label is less useful than the operating facts. Buyers should choose the arrangement that makes important work dependable at a cost and level of control they can sustain. That may mean a subscription, a licence, a managed service or a hybrid of all three.

Before rollout, establish who approves new integrations, who reviews privileged accounts and who owns renewal evidence. These small controls protect against a common failure: a service spreading through normal work until no one can explain its commercial, security or continuity assumptions.

Supplier choices become customer risks when they affect access, price, security or compatibility. That is why a vendor’s change process belongs in due diligence. The customer needs advance information and a realistic way to assess material consequences before routine work is disrupted.

Access replaced the simple story of ownership

A software buyer has rarely owned the underlying copyright. The meaningful difference is between an enduring right to use a defined version and time-limited access to an operated service, often with data held inside that service. The way software is sold now shapes the way it behaves in practice. A modern service may be easier to start, easier to update and easier to share, yet it is also usually more dependent on the supplier’s systems and terms. The buyer is therefore choosing both a tool and a continuing arrangement for running it.

A perpetual product may remain usable after support ends, although compatibility and security can deteriorate. A subscription may end when the contract ends, which makes export rights and post-termination access practical concerns. Packaging did more than carry code. It forced a moment of commitment, from the supplier and from the buyer. Digital delivery made commitment more fluid: a trial could begin instantly, a feature could be enabled remotely and a plan could be changed without a new copy. The new flexibility depends on reliable identity, payment and support systems.

The contract now bundles application function with hosting, updates, storage, identity and support. That bundle can be convenient, but it makes it essential to distinguish what continues after payment stops from what disappears. A service company lives with its customers after the deal closes. That is a meaningful contrast with a pure one-time sale. The company continues to incur hosting, support and development costs, while customers continue to judge availability, change and usefulness. The relevant standard is whether the continuing charge corresponds to a continuing service.

Data portability is not the same as operational portability. Exporting rows, files or records may be straightforward while moving history, permissions, workflow logic and integrations requires far more work. The apparent simplicity of SaaS can hide complex dependencies. Shared data, account roles, automated actions and third-party connections become part of the same operating picture. Leaders should know which business processes rest on that picture and which contingency exists when a key part is unavailable.

Typical differences between a perpetual licence and a hosted subscription

The comparison is illustrative. The licence, deployment design and contract determine the real allocation of control.

EU data protection law provides a personal-data portability right in defined circumstances, while the EU Data Act addresses obstacles to switching data-processing services. Those rules matter, but they do not erase technical migration work. The benefits are real, but the risks have moved rather than vanished. Central release management can reduce local patching while increasing reliance on the supplier’s judgment and availability. Flexible pricing can make a service accessible while making long-term cost harder to see. The buyer needs evidence, not a broad promise of convenience.

A service must survive ordinary stress. The supplier’s incentives should be read through product behaviour. Does the service make it easy to remove unused users, retrieve records, understand changes and reduce a plan? Or does every route lead toward more commitment and less clarity? No single answer settles the question, but the pattern matters. Companies that expect to retain customers through ongoing value usually invest in making the relationship understandable, even when the customer chooses to buy less.

The service is more than the interface. Customers should also avoid a false comparison between a perfect local system and a flawed subscription. Local software brings its own risks: delayed patches, unsupported versions, weak backups, lost specialist knowledge and difficulty reaching distributed users. The issue is not which side has risks. It is whether the selected allocation of responsibility fits the people and processes that must carry it.

The best buyers avoid both extremes. They do not assume a subscription will remove all work, and they do not assume a local product will guarantee independence. They decide where responsibility should sit, document that choice and revisit it when the workload changes. Software is not static because the organisation using it is not static. A sound model has room for new needs without hiding new exposure.

Read exit provisions before adopting the service. The quality of an export path says more about practical control than the marketing language around ownership. The durable advantage is clarity. A buyer that understands the real operating model can accept useful dependence while avoiding needless fragility. That is a more durable position than a simple preference for boxes or subscriptions.

Do not confuse faster deployment with lower complexity. The complexity may simply move into identity configuration, data ownership, user training and supplier management. A short implementation can still create a long relationship, which is why the design choices deserve a durable written record.

Review the commitment while alternatives remain practical.

Enterprise systems made the service model durable

Enterprise software rarely ends with installation. A finance, human resources, CRM or workflow system becomes useful through configuration, data quality, access roles, integration and ordinary user practice. The old commercial boundary was tangible. It was a release, a licence key and often a physical object, so it was easy to imagine that the transaction had finished the relationship. The modern service exposes the continuing part: operating the product, changing it, securing it and keeping the account useful. That is more than a different payment schedule. It changes which party must act when the technology, the user base or the threat environment changes.

Those ongoing requirements made subscriptions attractive for both sides. The customer receives a service that is operated and updated; the supplier receives an ongoing commercial relationship that can support continuing product work. Release timing followed the constraints of delivery. A vendor had to decide what was ready enough to ship and what could wait for a later version. Network channels weakened that discipline by making corrections, trials and plan changes available without a new retail run. The supplier could act more quickly, but customers also gained a product that could change underneath established routines.

Workday reported $7.7 billion in subscription services revenue for fiscal 2025, while its filing also identifies material costs of subscription delivery, including data-centre capacity and personnel. The numbers show that a service model carries both recurring income and recurring operating cost. Revenue recognition reflects a delivery promise over time. That makes retention, expansion and support quality part of the supplier’s financial model, not merely after-sales concerns. It can fund steady product work and service operation, but it can also create pressure to raise switching costs. Buyers should distinguish a product that earns renewal from one that merely makes exit difficult.

Enterprise adoption does not remove implementation effort. It often moves the focus from servers and installations toward process design, identity governance, data migration and vendor management. Software selection has become a question of operational design. The tool may be one component among accounts, permissions, databases, integrations and support processes. A useful inventory records each dependency before it becomes invisible through familiarity.

Large organisations also create a risk of scattered ownership. A department may adopt a service before security, legal, finance and integration owners understand what data it will hold or how it will fit existing controls. The customer still carries important responsibilities. A provider can operate infrastructure, but it cannot decide which employees should retain access, which data may be shared or what level of interruption the business can tolerate. Governance remains necessary, although its focus changes from installations to service oversight.

Test the operational claim directly. Migration deserves attention even when no change is planned. The customer does not need a complete replacement project on day one, but it should know whether data can be extracted, whether audit records and attachments travel with it, and which custom processes would need rebuilding. This knowledge improves negotiating leverage and makes a future change less traumatic. It also disciplines the design of the current implementation by discouraging undocumented shortcuts.

Context determines whether the trade works. Support quality often separates a service relationship from a simple licence. The customer needs to know who can open a case, what information will be available during an incident, which response commitments apply and how escalation works. A low-cost plan with no realistic support route may be appropriate for a low-consequence tool and wholly unsuitable for a service that holds critical records.

Practical diligence is modest but specific. Test one important workflow, inspect the administrator controls, read the change-notice process and ask for a realistic export example. A buyer does not need to predict every future event. It does need enough evidence to know where the service boundary sits and who will act when a problem crosses it. That preparation is cheaper before adoption than during a forced migration.

Make each enterprise service answerable to named business and technical owners. A subscription contract is not a substitute for operational accountability. A strong decision starts with the exit as well as the start. When teams understand cost, control, data and recovery before adoption, they are better able to use a service confidently and to challenge a renewal when terms no longer fit.

Service choice is strongest when the customer knows which work is genuinely being outsourced and which work remains inside the organisation. That division should be explicit in practice.

Record the evidence before the next renewal changes the bargaining position.

Consumer subscriptions grew through convenience and devices

Consumer software followed a different route. People increasingly expect files, preferences and purchases to follow them across phones, tablets and computers, which makes account-based service delivery feel ordinary. Software stopped being judged only at the point of sale. A package once implied a relatively stable thing that a buyer could install and keep. Subscription delivery foregrounds the work that continues after purchase: access management, service operation, updates, support and retention of customer material. The commercial model matters because those duties do not disappear; they are reassigned, priced and governed in different ways.

Creative suites, storage services and personal productivity tools can provide real ongoing value through updates, online files, collaboration and access on multiple devices. The initial cost may be lower than a large perpetual purchase. The old release cycle was partly a logistics problem. Media, manuals, stock and channel relationships placed a premium on a version that could stand still for a while. Online delivery shifted the emphasis from manufacturing to version management, service availability and the design of a direct customer channel.

Adobe’s annual reporting describes a business in which subscriptions are central to revenue recognition and annualised recurring revenue. The company is an example of a major creative-software publisher whose commercial model is built around continuing access. The financial model values relationships that persist. That can turn attention toward onboarding, prevention of incidents and practical customer success. It can also turn attention toward metrics that look healthy while hiding dissatisfied but trapped customers. Contracts, exports and support quality reveal which version a supplier is pursuing.

The consumer downside is just as concrete. Someone who uses a program only a few times a year may pay indefinitely for capacity they rarely need. Cancellation can also create anxiety about stored files or project formats. The running system is now the unit of analysis. A product that appears simple at the user level may connect to identity services, stored records, automations and administrative roles. Those links create value, but they also create consequences if a provider outage, account issue or contract termination interrupts access.

Fair consumer subscription design gives a clear price, a straightforward cancellation path and a practical way to keep or export personal material. These are product-quality questions as much as legal ones. The risk is usually in the boundary between provider and customer. Security, resilience and cost control depend on both parties performing their respective tasks. A contract that is vague about that boundary invites failure at the moment a decision is most urgent.

Check the service at its edges. The long-term value of any software model is measured in recoverability. Can the organisation continue essential work during an outage? Can it understand the effect of an update? Can it obtain what it needs if the contract ends? These are not dramatic hypotheticals. They are ordinary management questions for services that hold valuable information and shape routine decisions. Clear answers make adoption safer and renewal more rational.

The operating detail decides the outcome. Ultimately, the useful discipline is to make assumptions testable. Record the expected users, the expected data, the expected workflow and the expected cost; then review them against actual use. This turns a subscription from an automatic recurring expense into an operating choice that can be improved, reduced, replaced or renewed with evidence.

Contracts should not be read only by procurement staff. The people responsible for security, records, finance and the business process should each test the terms that affect them. A good supplier relationship allows these questions to be answered plainly. It does not rely on the buyer discovering a limitation after data and users have become deeply embedded. Shared understanding is a form of resilience.

Offer recurring access where the ongoing service is visible. Preserve a local or lower-cost path where the customer mainly needs an occasional, stable tool. Use the commercial model as a design choice. A service can be the better answer where common operation and current access solve a real problem. A perpetual or self-managed option can be the better answer where stability, local authority or offline continuity dominate. The sound choice is the one whose trade-offs are explicit.

Before rollout, establish who approves new integrations, who reviews privileged accounts and who owns renewal evidence. These small controls protect against a common failure: a service spreading through normal work until no one can explain its commercial, security or continuity assumptions.

That discipline makes the later decision more factual and less hurried.

Review the commitment while alternatives remain practical.

Mobile platforms normalised account-based software

Mobile app stores taught users to expect instant download, frequent updates, account sign-in and low initial prices. That experience changed expectations far beyond phones. The decisive change was in the relationship, not in the checkout page. A boxed purchase put emphasis on possession of a copy and a defined version. A subscription brings a continuing promise of access to a service that the supplier operates. The buyer therefore needs to consider the service’s behaviour over time, including its release cadence, account controls, data handling and path out.

App distribution gives developers a direct route to users, a payment mechanism and a channel for delivery. It also places platform rules, store approval and operating-system changes between the developer and the customer. Physical media made software feel more self-contained than it usually was. Updates, support and compatibility still existed, but they were less visible in the commercial story. Direct digital delivery brought those activities closer to the product and made them available on a much shorter cycle.

Subscriptions fit mobile products when the service includes continuing content, storage, communications or computation. They are harder to justify where the app is a simple, self-contained utility with little continuing cost. Recurring income changes the decisions inside a software company. Product teams, account teams and finance functions all gain reason to care about the life of the relationship. That can produce better service. It can also produce excessive tiering, opaque bundles and a habit of treating cancellation friction as a commercial asset.

Mobile products often rely on identity and cloud synchronisation, so a lost password or account suspension can become more disruptive than a lost device. The product is partly on the handset and partly in the service. The operational dependency is usually broader than the visible feature set. A customer may be choosing an account structure, a storage location, a logging model and a chain of integrations as well as an interface. Before adoption, teams should identify what work stops if access fails, which data becomes unavailable and which internal controls rely on the service.

Platform convenience can hide the division of responsibility. The store may process payment, the developer may operate the service and another supplier may host data. Customers need clear routes for support and cancellation. A good service relationship makes its limits visible. It explains what is managed centrally, what the customer must configure, how change is communicated and what happens in an incident. Hidden assumptions are more dangerous than imperfect technology.

Evidence beats a feature-list promise. Pricing deserves the same scrutiny as architecture. The buyer should identify the unit that causes a bill to rise, the person who monitors that unit, and the action available when usage moves beyond plan. This is especially important for services that price storage, transactions or advanced computing. A price model can be sensible and still become risky when its measurement is invisible to the people responsible for the budget.

A clean contract needs usable practice. An implementation plan should preserve an independent record of important decisions. Keep copies of configuration choices, integration mappings, user roles, data categories and contract commitments in places the supplier does not control. This does not create independence from the service, but it makes the customer less dependent on memory and more able to assess a problem or a future transition.

Service providers benefit from the same clarity. They can state which functions they operate, which customer responsibilities remain, which limits apply and how a customer can prepare for change. Clear boundaries reduce support disputes and help customers see the continuing value of the service. Ambiguity may accelerate a sale, but it weakens renewal confidence and makes every incident harder to resolve.

Design mobile subscriptions around a real ongoing service, not merely around the fact that recurring billing is technically easy. The next renewal should never be the first serious review. Sound selection creates a record of assumptions, owners and export needs at the start. That record makes the later decision calmer, more factual and less vulnerable to pressure.

Do not confuse faster deployment with lower complexity. The complexity may simply move into identity configuration, data ownership, user training and supplier management. A short implementation can still create a long relationship, which is why the design choices deserve a durable written record.

One clear owner, one current system record and one scheduled renewal review will prevent many avoidable surprises. The aim is informed control, not procedural theatre.

Test one important assumption before it becomes an expensive surprise.

Collaboration made software less solitary

Subscriptions became more compelling when software stopped being a private tool on one computer and became a shared place where people work together. Documents, tasks, messages and design files increasingly exist as live, shared objects. A software purchase is now often a live operating arrangement. The shift is visible in recurring invoices, but the deeper change is technical and organisational. Code, data, identity, support and release management are joined together in a service that must keep functioning after the original procurement decision. The question for buyers is not just what feature is present today, but which obligations persist tomorrow.

Collaboration depends on persistent identity, permissions, version history, presence information and storage. Those functions are easier to run as a service than to recreate separately on every user’s device. The delivery channel influenced the product itself. Packaging, distribution and installation requirements encouraged large, visible releases. Once the network became the normal path, a supplier could publish smaller changes, revise documentation and serve a user directly. Faster delivery is useful only when customers can see what changed and prepare where preparation is needed.

Shared work raises the value of continuity. A team does not merely lose access to a program when a service fails; it may lose its meeting record, decision trail, current files and coordination mechanism. The supplier’s success became tied to continued use. A major subscription business cannot rely solely on a launch peak; it has to maintain a service customers regard as worth renewing. The healthier version of that incentive rewards reliability, adoption and clear support. The darker version uses complex packaging or hard-to-move data to delay cancellation.

The commercial result is a stronger relationship between customer and provider. The more people build routine work around shared spaces, the more difficult it becomes to replace the service without careful change management. A subscription service carries a hidden map of dependencies. It includes people, permissions, data, vendors and automated processes. Making that map explicit before rollout is a practical way to reduce surprise later.

That dependence is not inherently bad. It can be justified by useful features such as simultaneous editing and remote access. It becomes dangerous when the organisation has no inventory of shared systems or no export plan. The benefits are real, but the risks have moved rather than vanished. Central release management can reduce local patching while increasing reliance on the supplier’s judgment and availability. Flexible pricing can make a service accessible while making long-term cost harder to see. The buyer needs evidence, not a broad promise of convenience.

Make the hidden dependencies visible. Useful comparisons look beyond feature lists. Two tools may both claim collaboration, security or automation, while assigning very different responsibilities for permissions, storage, integration recovery and support. The buyer should write down the precise workflow that matters, then test each candidate against it. A tool that wins a broad feature comparison can still lose when measured against the one process that must remain reliable during absence, growth or disruption.

Independence is measured in recovery. The right level of customisation deserves restraint. A service may offer scripting, low-code workflows and extensive integrations, but every local adaptation creates a maintenance burden and can raise the future cost of switching. Customisation should be reserved for work that genuinely distinguishes the organisation or meets a real control need, not for recreating every historical preference.

Good governance starts with a basic distinction between reversible and hard-to-reverse choices. A plan tier or seat count can often be changed. A platform that holds records, automations and working habits cannot. Put more research into the decision that is difficult to unwind, and retain enough internal knowledge to challenge a renewal rather than simply accepting the default path. That is a commercial discipline as well as a technical one.

Treat collaboration services as business infrastructure once they hold material records. Their apparent simplicity should not reduce the seriousness of governance. The practical test is whether responsibility is visible and manageable. A contract is not a substitute for an operating plan, and a perpetual licence is not a substitute for maintenance capability. Match the model to the work rather than forcing the work into a fashionable pricing structure.

Supplier choices become customer risks when they affect access, price, security or compatibility. That is why a vendor’s change process belongs in due diligence. The customer needs advance information and a realistic way to assess material consequences before routine work is disrupted.

Review the commitment while alternatives remain practical.

Telemetry gave vendors a closer view of use

Connected software gives vendors information that boxed products rarely provided at scale: crash signals, feature use, performance data, account activity and adoption patterns. The precise scope varies by product and settings. The box concealed the amount of ongoing work behind a single sale. The service model makes that work visible because someone must operate the environment, handle new risks, respond to customer needs and keep the product compatible with the world around it. A good analysis tracks where those tasks move, who pays for them and what happens when the supplier changes course.

That feedback can improve product decisions. A team can identify a failing release, see whether a new feature is confusing or understand which parts of a workflow are rarely completed. What looked like a product calendar was also a distribution calendar. Once that calendar loosened, product teams could respond more quickly to failures and customer signals. They could also change more often than customers expected. That is why operational notice and release documentation became more valuable, not less.

Telemetry also changes power. The provider may know more about product behaviour across its customer base than any individual customer knows about its own configuration, especially when the service is centrally operated. The invoice is now an ongoing referendum on the product. Customers may renew because the service works, because their organisation is deeply integrated or because leaving feels too costly. These motives should not be conflated. A strong buyer asks whether the provider’s commercial model gives it reason to improve the service or merely reason to make the service sticky.

Privacy and contract terms matter because usage data can be personal data or sensitive business information depending on context. A responsible customer asks what is collected, for what purpose, how long it is retained and who can access it. The account has become as important as the installed code. A buyer should examine administration, recovery, records and integration ownership alongside the user experience. Those details decide whether the service remains usable under pressure.

Analytics can make services better, but it should not be used as a vague excuse for unlimited observation. The data should match a stated operational or product purpose, and the account owner should be able to understand the setting. The customer still carries important responsibilities. A provider can operate infrastructure, but it cannot decide which employees should retain access, which data may be shared or what level of interruption the business can tolerate. Governance remains necessary, although its focus changes from installations to service oversight.

Test the workflow under pressure. Different stakeholders see different costs. Finance sees committed and variable spend. Security sees identity, logging and incident exposure. Legal sees terms, processing and responsibility. Users see whether the work is easier or harder. A decision that ignores one of these views often creates a later conflict. The purpose of cross-functional review is not to slow every purchase; it is to identify the dependencies that deserve a deliberate owner.

Cost depends on the whole system. History gives the comparison some humility. Maintenance agreements, hosted applications and time-limited rights existed before the current SaaS market. The newer model became dominant where broadband, web standards, cloud infrastructure and account-based delivery made the continuous service easier to operate and easier to sell. The relevant change is cumulative: technology, finance and user expectations reinforced one another.

Customer control does not require total technical ownership. It requires enough information and ability to make informed choices: who can access the service, what data can leave it, what changes are planned, what the bill measures and what happens at termination. Those are ordinary requirements for a dependable operating relationship. They become especially important when the service supports revenue, compliance or core records.

Make telemetry part of diligence. A recurring service is not only delivered to the user; it may also return signals to the supplier. The decision should be made before dependence accumulates. The appropriate model follows the workload, the organisation’s capacity to operate technology and the consequences of interruption. A recurring service is valuable when its continuous work is real and visible. A local licence remains defensible when independence and timing control matter more.

Do not confuse faster deployment with lower complexity. The complexity may simply move into identity configuration, data ownership, user training and supplier management. A short implementation can still create a long relationship, which is why the design choices deserve a durable written record.

Keep the service boundary visible to the people who depend on it.

Security maintenance became a service obligation

Security is one reason subscriptions gained force. Internet-connected products face a continuing stream of vulnerabilities, configuration mistakes and identity threats that cannot be solved by a one-time release. The market moved from discrete releases to continuing obligations. A customer no longer evaluates only a copy of the code; it evaluates a provider’s ability to deliver access, protect information, support users and manage change. That matters because the practical cost of a bad supplier decision usually appears long after a contract has been signed.

A provider that operates a service can patch common infrastructure and application code centrally. It can also monitor for unusual activity and improve controls without waiting for each customer to deploy a new version. Retail supply chains made revision slow by design. When software became network-delivered, the economics of a small fix changed. A vendor could issue it quickly, observe its effects and adjust again. That capacity is valuable, but it puts more importance on responsible control of the release process.

NIST guidance on public cloud security and privacy describes security and privacy concerns that arise when organisations use public cloud services. The point is not that cloud is unsafe; it is that risk must be understood across the provider and customer boundary. Commercial attention moved from the next upgrade to the next renewal. Vendors now have reason to measure whether customers remain active, grow their use and receive enough value to continue. Those measures can improve product discipline, but they are not proof of customer benefit. A renewal driven by genuine utility is different from one driven by accumulated dependence.

Central patching does not absolve customers. Weak administrator settings, excessive privileges, unmanaged accounts and unsafe integrations can undermine a well-run service. Identity and configuration remain live responsibilities. A modern product is often an information system rather than a standalone program. Its operational value comes from connections that are easy to overlook during a feature demonstration. The right diligence asks where data travels, which identities govern it and which workflows would fail at short notice.

CISA’s secure-by-demand guidance gives customers a procurement role: they can demand secure default behaviour, better security evidence and usable incident information. That changes the buyer from passive recipient to an active security stakeholder. The risk is usually in the boundary between provider and customer. Security, resilience and cost control depend on both parties performing their respective tasks. A contract that is vague about that boundary invites failure at the moment a decision is most urgent.

Ask who carries each responsibility. Service quality is often most visible at the edge cases. A normal login, normal invoice and normal update reveal little. A departing employee, a contested bill, an integration failure or a request for a complete export reveals much more. Organisations should treat these moments as tests of the vendor relationship. The result should inform renewal decisions and internal controls, not disappear into one support ticket or one person’s memory.

Controls matter after deployment too. Where services contain personal or confidential information, data handling needs more than a generic assurance. The customer should know the relevant processing roles, retention choices, regional commitments, subcontracting arrangements and administrative controls. The exact legal analysis depends on jurisdiction and context, but the operational need for clear answers exists in every serious deployment.

Before a decision is locked in, create a short operating record. Name the business owner, the technical owner, the data involved, the identity route, the important integrations, the renewal date and the extraction route. None of this is bureaucratic decoration. It is the evidence needed to decide later whether the service still matches the work. A provider that welcomes those questions is more likely to be prepared for a mature relationship.

Ask a provider who patches what, which logs are available, how incidents are communicated and what the customer must configure. The answers belong in the operating plan. Choose deliberate dependence over accidental lock-in. Every important system depends on somebody. The goal is to make the dependency proportionate to the value received, clear in contract and technical design, and recoverable if circumstances change.

Do not confuse faster deployment with lower complexity. The complexity may simply move into identity configuration, data ownership, user training and supplier management. A short implementation can still create a long relationship, which is why the design choices deserve a durable written record.

Price, access and data should be reviewed together. Separating them into different meetings often hides the trade-offs that make a subscription attractive or risky.

Identity became the new installation

For much subscription software, access begins with an identity provider, an account and a permission set rather than a disc and an installer. The shift changes both convenience and risk. The commercial label hides an architectural decision. A perpetual licence and a subscription distribute control, operating work and financial exposure differently. The former tends to make a version durable on the customer side; the latter tends to make a service current on the provider side. Neither arrangement is automatically superior, because the workload and the customer’s capacity to govern it remain decisive.

Single sign-on, multifactor authentication and central role management can reduce friction and improve control. They also turn the identity system into a dependency whose failure can block many services at once. Distribution used to impose a hard rhythm on development. A release was expensive to manufacture and support, so feature groups often travelled together. Internet delivery reduced the cost of frequent revision and gave companies a route around retail intermediaries. It also made the supplier’s account system and service continuity part of the customer’s daily experience.

Account administration deserves the same attention that organisations once gave device deployment. Joiner, mover and leaver processes decide who has access; group rules and role mappings decide what they can do. Recurring revenue makes continuity commercially visible. The vendor must plan for service delivery across the term, while the customer must plan for repeated payment and renewal. The advantage is a closer alignment between use and payment; the risk is a closer alignment between dependence and pricing power.

Subscription services often store more than documents. They may hold tokens, connected apps, exports, audit records and automated actions. A poorly managed administrator account can therefore carry broad operational authority. The software cannot be separated cleanly from its surrounding service. Access rules, data retention, integrations and support routes determine what users can actually do. They also determine how a problem spreads when something changes or fails.

NIST access-control guidance for cloud systems treats cloud access as a distinct management problem. In practice, teams should know which accounts are privileged, which permissions are delegated and how emergency access is handled. A good service relationship makes its limits visible. It explains what is managed centrally, what the customer must configure, how change is communicated and what happens in an incident. Hidden assumptions are more dangerous than imperfect technology.

Write down the real failure path. Evidence should be sought at the level of daily work. A service page or sales presentation is not enough when the product will hold records or coordinate a critical process. Ask to see the administrative view, the export function, the permission model and the process for reporting a fault. These details show whether the provider treats the customer as a partner in operations or as a passive user of an opaque system. They also reveal which skills the customer must retain.

Exit quality reveals real bargaining power. Metrics should be chosen carefully. Active seats, completed tasks, incident volume, time spent on manual work, support requests and export tests can all show whether a service is earning its cost. A dashboard of vanity usage figures is less helpful than a small set of measures tied to the business process the software was bought to improve.

An organisation should review the service at moments that reveal its true character: a material update, an incident, a price change, a major integration or an approaching renewal. These events create useful evidence about documentation, support, notice and recovery. They also reveal whether the supplier’s promises match the way the service behaves under pressure. A decision record prevents those lessons from being lost between teams.

Build identity governance into the selection of a subscription product. The product is only as controllable as the access model surrounding it. The label is less useful than the operating facts. Buyers should choose the arrangement that makes important work dependable at a cost and level of control they can sustain. That may mean a subscription, a licence, a managed service or a hybrid of all three.

Keep the decision grounded in a real operating scenario, such as a critical user leaving, a supplier incident, a price change or a request for complete records. Those scenarios convert abstract preference into testable responsibilities and expose the information that the customer will need under pressure.

Service choice is strongest when the customer knows which work is genuinely being outsourced and which work remains inside the organisation. That division should be explicit in practice.

Integration turned subscriptions into systems

A standalone boxed program could be valuable on its own. Modern subscriptions often gain their value by connecting to payments, calendars, customer data, storage, analytics and other services. The way software is sold now shapes the way it behaves in practice. A modern service may be easier to start, easier to update and easier to share, yet it is also usually more dependent on the supplier’s systems and terms. The buyer is therefore choosing both a tool and a continuing arrangement for running it.

APIs and connectors reduce manual work, but they also create chains of dependence. A change in one service’s permissions, pricing or API policy can affect a process that appears to belong to another service. Packaging did more than carry code. It forced a moment of commitment, from the supplier and from the buyer. Digital delivery made commitment more fluid: a trial could begin instantly, a feature could be enabled remotely and a plan could be changed without a new copy. The new flexibility depends on reliable identity, payment and support systems.

Integration moves software selection beyond feature comparison. The buyer must consider data mapping, authentication, error handling, monitoring, ownership and the effort required to replace a connector later. A service company lives with its customers after the deal closes. That is a meaningful contrast with a pure one-time sale. The company continues to incur hosting, support and development costs, while customers continue to judge availability, change and usefulness. The relevant standard is whether the continuing charge corresponds to a continuing service.

Subscriptions make integrations easier to offer and easier to update, since the provider operates a shared service. They can also make upgrades harder to control because a vendor may alter an endpoint or retire a legacy method. The apparent simplicity of SaaS can hide complex dependencies. Shared data, account roles, automated actions and third-party connections become part of the same operating picture. Leaders should know which business processes rest on that picture and which contingency exists when a key part is unavailable.

An integration is a business commitment, not a decorative add-on. It should have a named owner, a record of what data moves through it and a fallback for the tasks that would fail if it stopped. The benefits are real, but the risks have moved rather than vanished. Central release management can reduce local patching while increasing reliance on the supplier’s judgment and availability. Flexible pricing can make a service accessible while making long-term cost harder to see. The buyer needs evidence, not a broad promise of convenience.

A service must survive ordinary stress. The supplier’s incentives should be read through product behaviour. Does the service make it easy to remove unused users, retrieve records, understand changes and reduce a plan? Or does every route lead toward more commitment and less clarity? No single answer settles the question, but the pattern matters. Companies that expect to retain customers through ongoing value usually invest in making the relationship understandable, even when the customer chooses to buy less.

The service is more than the interface. Customers should also avoid a false comparison between a perfect local system and a flawed subscription. Local software brings its own risks: delayed patches, unsupported versions, weak backups, lost specialist knowledge and difficulty reaching distributed users. The issue is not which side has risks. It is whether the selected allocation of responsibility fits the people and processes that must carry it.

The best buyers avoid both extremes. They do not assume a subscription will remove all work, and they do not assume a local product will guarantee independence. They decide where responsibility should sit, document that choice and revisit it when the workload changes. Software is not static because the organisation using it is not static. A sound model has room for new needs without hiding new exposure.

Map critical dependencies before a renewal or migration. The most serious switching costs are often hidden in automated connections rather than in the visible user interface. The durable advantage is clarity. A buyer that understands the real operating model can accept useful dependence while avoiding needless fragility. That is a more durable position than a simple preference for boxes or subscriptions.

Do not confuse faster deployment with lower complexity. The complexity may simply move into identity configuration, data ownership, user training and supplier management. A short implementation can still create a long relationship, which is why the design choices deserve a durable written record.

Review the commitment while alternatives remain practical.

Lock-in shifted from code to accumulated work

Vendor lock-in is not only a technical property of a closed format. It grows when a company accumulates data, workflows, identities, training, integrations, reports and habits around one service. The old commercial boundary was tangible. It was a release, a licence key and often a physical object, so it was easy to imagine that the transaction had finished the relationship. The modern service exposes the continuing part: operating the product, changing it, securing it and keeping the account useful. That is more than a different payment schedule. It changes which party must act when the technology, the user base or the threat environment changes.

A provider may offer reasonable export and still be difficult to leave because the receiving system interprets the data differently or does not reproduce the business logic built over years of use. Release timing followed the constraints of delivery. A vendor had to decide what was ready enough to ship and what could wait for a later version. Network channels weakened that discipline by making corrections, trials and plan changes available without a new retail run. The supplier could act more quickly, but customers also gained a product that could change underneath established routines.

Lock-in can be commercially justified when a deep platform genuinely supports complex work. It becomes problematic when exit information is vague, interfaces are unnecessarily restricted or pricing pressure rises after dependence has formed. Revenue recognition reflects a delivery promise over time. That makes retention, expansion and support quality part of the supplier’s financial model, not merely after-sales concerns. It can fund steady product work and service operation, but it can also create pressure to raise switching costs. Buyers should distinguish a product that earns renewal from one that merely makes exit difficult.

The cost of leaving is not always a reason to avoid a service. It is a reason to identify the cost early and decide whether the value delivered is worth it. Unmeasured dependence is the real danger. Software selection has become a question of operational design. The tool may be one component among accounts, permissions, databases, integrations and support processes. A useful inventory records each dependency before it becomes invisible through familiarity.

The EU Data Act contains provisions intended to remove obstacles to effective switching between data-processing services, and it addresses contractual transparency, switching charges and technical aspects of switching. Those rules do not promise a zero-effort migration. The customer still carries important responsibilities. A provider can operate infrastructure, but it cannot decide which employees should retain access, which data may be shared or what level of interruption the business can tolerate. Governance remains necessary, although its focus changes from installations to service oversight.

Test the operational claim directly. Migration deserves attention even when no change is planned. The customer does not need a complete replacement project on day one, but it should know whether data can be extracted, whether audit records and attachments travel with it, and which custom processes would need rebuilding. This knowledge improves negotiating leverage and makes a future change less traumatic. It also disciplines the design of the current implementation by discouraging undocumented shortcuts.

Context determines whether the trade works. Support quality often separates a service relationship from a simple licence. The customer needs to know who can open a case, what information will be available during an incident, which response commitments apply and how escalation works. A low-cost plan with no realistic support route may be appropriate for a low-consequence tool and wholly unsuitable for a service that holds critical records.

Practical diligence is modest but specific. Test one important workflow, inspect the administrator controls, read the change-notice process and ask for a realistic export example. A buyer does not need to predict every future event. It does need enough evidence to know where the service boundary sits and who will act when a problem crosses it. That preparation is cheaper before adoption than during a forced migration.

Treat exit as a design criterion. Document what can be exported, who owns the extraction, how long it takes and which business processes need rebuilding. A strong decision starts with the exit as well as the start. When teams understand cost, control, data and recovery before adoption, they are better able to use a service confidently and to challenge a renewal when terms no longer fit.

Record the evidence before the next renewal changes the bargaining position.

Clear records keep technical, commercial and business assumptions connected.

Review the commitment while alternatives remain practical.

Data portability became a competitive issue

Data portability moved from a technical detail to a market question because subscriptions often hold the customer’s most useful operational history. A service is easier to leave when its records are recoverable and reusable. Software stopped being judged only at the point of sale. A package once implied a relatively stable thing that a buyer could install and keep. Subscription delivery foregrounds the work that continues after purchase: access management, service operation, updates, support and retention of customer material. The commercial model matters because those duties do not disappear; they are reassigned, priced and governed in different ways.

GDPR Article 20 gives data subjects a right to receive personal data they have provided to a controller in a structured, commonly used and machine-readable format in specified cases. It is a personal-data right, not a universal enterprise migration guarantee. The old release cycle was partly a logistics problem. Media, manuals, stock and channel relationships placed a premium on a version that could stand still for a while. Online delivery shifted the emphasis from manufacturing to version management, service availability and the design of a direct customer channel.

The EU Data Act applies from 12 September 2025 and includes rules intended to improve switching and portability between data-processing services. Its provisions also recognise limits, including intellectual-property protection and security considerations. The financial model values relationships that persist. That can turn attention toward onboarding, prevention of incidents and practical customer success. It can also turn attention toward metrics that look healthy while hiding dissatisfied but trapped customers. Contracts, exports and support quality reveal which version a supplier is pursuing.

Portability should be assessed in layers: raw records, attachments, metadata, audit history, permissions, configurations, integrations and user knowledge. A provider may handle one layer well and another poorly. The running system is now the unit of analysis. A product that appears simple at the user level may connect to identity services, stored records, automations and administrative roles. Those links create value, but they also create consequences if a provider outage, account issue or contract termination interrupts access.

Open interfaces and documented formats reduce unnecessary barriers, but they do not produce identical replacement services. The destination system may require different data structures, controls or business decisions. The risk is usually in the boundary between provider and customer. Security, resilience and cost control depend on both parties performing their respective tasks. A contract that is vague about that boundary invites failure at the moment a decision is most urgent.

Check the service at its edges. The long-term value of any software model is measured in recoverability. Can the organisation continue essential work during an outage? Can it understand the effect of an update? Can it obtain what it needs if the contract ends? These are not dramatic hypotheticals. They are ordinary management questions for services that hold valuable information and shape routine decisions. Clear answers make adoption safer and renewal more rational.

The operating detail decides the outcome. Ultimately, the useful discipline is to make assumptions testable. Record the expected users, the expected data, the expected workflow and the expected cost; then review them against actual use. This turns a subscription from an automatic recurring expense into an operating choice that can be improved, reduced, replaced or renewed with evidence.

Contracts should not be read only by procurement staff. The people responsible for security, records, finance and the business process should each test the terms that affect them. A good supplier relationship allows these questions to be answered plainly. It does not rely on the buyer discovering a limitation after data and users have become deeply embedded. Shared understanding is a form of resilience.

Use the legal direction of travel as a reason to demand clarity, not as an excuse to skip technical planning. Good exits are engineered before a crisis. Use the commercial model as a design choice. A service can be the better answer where common operation and current access solve a real problem. A perpetual or self-managed option can be the better answer where stability, local authority or offline continuity dominate. The sound choice is the one whose trade-offs are explicit.

Before rollout, establish who approves new integrations, who reviews privileged accounts and who owns renewal evidence. These small controls protect against a common failure: a service spreading through normal work until no one can explain its commercial, security or continuity assumptions.

Record the evidence before the next renewal changes the bargaining position.

That discipline makes the later decision more factual and less hurried.

The total-cost comparison needs more than price

A perpetual licence and a subscription cannot be compared honestly by placing one invoice next to one monthly price. The relevant cost includes operation, maintenance, people, upgrades, downtime risk and the effort of eventual change. The decisive change was in the relationship, not in the checkout page. A boxed purchase put emphasis on possession of a copy and a defined version. A subscription brings a continuing promise of access to a service that the supplier operates. The buyer therefore needs to consider the service’s behaviour over time, including its release cadence, account controls, data handling and path out.

The local model commonly places deployment, servers, backups, patching and skilled administration with the customer. The service model bundles more of that work into the provider’s charge, but adds recurring payment and external dependence. Physical media made software feel more self-contained than it usually was. Updates, support and compatibility still existed, but they were less visible in the commercial story. Direct digital delivery brought those activities closer to the product and made them available on a much shorter cycle.

Cloud services can reduce the need for local infrastructure and make access easier for distributed teams. They can also create spend that scales with users, data or transactions, requiring routine cost oversight. Recurring income changes the decisions inside a software company. Product teams, account teams and finance functions all gain reason to care about the life of the relationship. That can produce better service. It can also produce excessive tiering, opaque bundles and a habit of treating cancellation friction as a commercial asset.

The table below is a decision aid rather than a universal formula. Different workloads, contracts and regulatory requirements can reverse the result. What matters is making the assumptions explicit. The operational dependency is usually broader than the visible feature set. A customer may be choosing an account structure, a storage location, a logging model and a chain of integrations as well as an interface. Before adoption, teams should identify what work stops if access fails, which data becomes unavailable and which internal controls rely on the service.

Cost questions that belong in a like-for-like comparison

The table is a checklist, not a price verdict. A credible comparison also includes internal labour, risk and migration effort.

Costs that seem small in isolation can become material at scale: dormant seats, premium add-ons, migration support, API overages, retention storage, specialist administration and emergency consulting during an exit. A good service relationship makes its limits visible. It explains what is managed centrally, what the customer must configure, how change is communicated and what happens in an incident. Hidden assumptions are more dangerous than imperfect technology.

Evidence beats a feature-list promise. Pricing deserves the same scrutiny as architecture. The buyer should identify the unit that causes a bill to rise, the person who monitors that unit, and the action available when usage moves beyond plan. This is especially important for services that price storage, transactions or advanced computing. A price model can be sensible and still become risky when its measurement is invisible to the people responsible for the budget.

A clean contract needs usable practice. An implementation plan should preserve an independent record of important decisions. Keep copies of configuration choices, integration mappings, user roles, data categories and contract commitments in places the supplier does not control. This does not create independence from the service, but it makes the customer less dependent on memory and more able to assess a problem or a future transition.

Service providers benefit from the same clarity. They can state which functions they operate, which customer responsibilities remain, which limits apply and how a customer can prepare for change. Clear boundaries reduce support disputes and help customers see the continuing value of the service. Ambiguity may accelerate a sale, but it weakens renewal confidence and makes every incident harder to resolve.

Make the comparison over a realistic service life and include a scenario in which the supplier changes price, terms or product direction. The next renewal should never be the first serious review. Sound selection creates a record of assumptions, owners and export needs at the start. That record makes the later decision calmer, more factual and less vulnerable to pressure.

A credible exit plan includes both technical and human work. It identifies records, formats, attachments, permissions, automation, reports and the people who understand them. A raw database export may be necessary, yet it rarely restores the full working context that a mature service has accumulated.

Service choice is strongest when the customer knows which work is genuinely being outsourced and which work remains inside the organisation. That division should be explicit in practice.

Procurement became continuous governance

Traditional procurement often treated software as an acquisition project. Subscription software requires an earlier buying decision and a later pattern of governance: access review, spend review, security review, change review and renewal review. A software purchase is now often a live operating arrangement. The shift is visible in recurring invoices, but the deeper change is technical and organisational. Code, data, identity, support and release management are joined together in a service that must keep functioning after the original procurement decision. The question for buyers is not just what feature is present today, but which obligations persist tomorrow.

Contracts should identify the service, the data categories, the responsible owners, support arrangements, availability commitments, notification routes and the practical process for retrieval at termination. The delivery channel influenced the product itself. Packaging, distribution and installation requirements encouraged large, visible releases. Once the network became the normal path, a supplier could publish smaller changes, revise documentation and serve a user directly. Faster delivery is useful only when customers can see what changed and prepare where preparation is needed.

Enterprise buyers also need to consider subcontractors, geographic processing, incident communication and the provider’s capacity to meet applicable sector obligations. DORA, for example, places ICT third-party risk inside the operational-resilience framework for financial entities. The supplier’s success became tied to continued use. A major subscription business cannot rely solely on a launch peak; it has to maintain a service customers regard as worth renewing. The healthier version of that incentive rewards reliability, adoption and clear support. The darker version uses complex packaging or hard-to-move data to delay cancellation.

Good governance does not require endless committees. It requires a short record of the decisions that matter and a calendar that brings them back before renewal becomes automatic. A subscription service carries a hidden map of dependencies. It includes people, permissions, data, vendors and automated processes. Making that map explicit before rollout is a practical way to reduce surprise later.

The business owner should be able to explain why the service exists and how its value is measured. The technical owner should be able to explain identities, data flows, integrations, logs and recovery assumptions. The benefits are real, but the risks have moved rather than vanished. Central release management can reduce local patching while increasing reliance on the supplier’s judgment and availability. Flexible pricing can make a service accessible while making long-term cost harder to see. The buyer needs evidence, not a broad promise of convenience.

Make the hidden dependencies visible. Useful comparisons look beyond feature lists. Two tools may both claim collaboration, security or automation, while assigning very different responsibilities for permissions, storage, integration recovery and support. The buyer should write down the precise workflow that matters, then test each candidate against it. A tool that wins a broad feature comparison can still lose when measured against the one process that must remain reliable during absence, growth or disruption.

Independence is measured in recovery. The right level of customisation deserves restraint. A service may offer scripting, low-code workflows and extensive integrations, but every local adaptation creates a maintenance burden and can raise the future cost of switching. Customisation should be reserved for work that genuinely distinguishes the organisation or meets a real control need, not for recreating every historical preference.

Good governance starts with a basic distinction between reversible and hard-to-reverse choices. A plan tier or seat count can often be changed. A platform that holds records, automations and working habits cannot. Put more research into the decision that is difficult to unwind, and retain enough internal knowledge to challenge a renewal rather than simply accepting the default path. That is a commercial discipline as well as a technical one.

Treat renewal as a decision point, not a clerical event. It is the moment to test whether the supplier is still earning the relationship. The practical test is whether responsibility is visible and manageable. A contract is not a substitute for an operating plan, and a perpetual licence is not a substitute for maintenance capability. Match the model to the work rather than forcing the work into a fashionable pricing structure.

Use these checks as part of normal ownership, not as a one-time migration exercise. The service will keep changing after go-live, and the customer’s understanding should keep pace with it.

Service choice is strongest when the customer knows which work is genuinely being outsourced and which work remains inside the organisation. That division should be explicit in practice.

Open source and hybrid models survived the shift

Subscription growth did not eliminate open-source, self-hosted or hybrid software. These models remain useful where an organisation values code inspection, deployment control, offline operation or a particular integration path. The box concealed the amount of ongoing work behind a single sale. The service model makes that work visible because someone must operate the environment, handle new risks, respond to customer needs and keep the product compatible with the world around it. A good analysis tracks where those tasks move, who pays for them and what happens when the supplier changes course.

Open source changes the commercial question rather than removing it. A company may pay for hosting, support, consulting, managed operation or enterprise features while retaining more freedom to inspect and modify the code. What looked like a product calendar was also a distribution calendar. Once that calendar loosened, product teams could respond more quickly to failures and customer signals. They could also change more often than customers expected. That is why operational notice and release documentation became more valuable, not less.

Hybrid deployments are common when a business keeps sensitive, latency-sensitive or legacy workloads under local control while using hosted services for collaboration, analytics or elastic capacity. The invoice is now an ongoing referendum on the product. Customers may renew because the service works, because their organisation is deeply integrated or because leaving feels too costly. These motives should not be conflated. A strong buyer asks whether the provider’s commercial model gives it reason to improve the service or merely reason to make the service sticky.

The trade-off is practical. Local control requires operating skill, patch discipline, backup design and capacity planning. Hosted convenience reduces some internal burden but places more weight on the provider relationship. The account has become as important as the installed code. A buyer should examine administration, recovery, records and integration ownership alongside the user experience. Those details decide whether the service remains usable under pressure.

An open-source licence does not automatically make migration easy, and a SaaS contract does not automatically create lock-in. Formats, data models, integrations and staff knowledge determine the real switching position. The customer still carries important responsibilities. A provider can operate infrastructure, but it cannot decide which employees should retain access, which data may be shared or what level of interruption the business can tolerate. Governance remains necessary, although its focus changes from installations to service oversight.

Test the workflow under pressure. Different stakeholders see different costs. Finance sees committed and variable spend. Security sees identity, logging and incident exposure. Legal sees terms, processing and responsibility. Users see whether the work is easier or harder. A decision that ignores one of these views often creates a later conflict. The purpose of cross-functional review is not to slow every purchase; it is to identify the dependencies that deserve a deliberate owner.

Cost depends on the whole system. History gives the comparison some humility. Maintenance agreements, hosted applications and time-limited rights existed before the current SaaS market. The newer model became dominant where broadband, web standards, cloud infrastructure and account-based delivery made the continuous service easier to operate and easier to sell. The relevant change is cumulative: technology, finance and user expectations reinforced one another.

Customer control does not require total technical ownership. It requires enough information and ability to make informed choices: who can access the service, what data can leave it, what changes are planned, what the bill measures and what happens at termination. Those are ordinary requirements for a dependable operating relationship. They become especially important when the service supports revenue, compliance or core records.

Choose the operating model that matches the team’s ability to run it. Ideological preference is a poor substitute for an honest assessment of responsibility. The decision should be made before dependence accumulates. The appropriate model follows the workload, the organisation’s capacity to operate technology and the consequences of interruption. A recurring service is valuable when its continuous work is real and visible. A local licence remains defensible when independence and timing control matter more.

A credible exit plan includes both technical and human work. It identifies records, formats, attachments, permissions, automation, reports and the people who understand them. A raw database export may be necessary, yet it rarely restores the full working context that a mature service has accumulated.

Use these checks as part of normal ownership, not as a one-time migration exercise. The service will keep changing after go-live, and the customer’s understanding should keep pace with it.

On-premises software still has real uses

Local and on-premises deployments have not disappeared because some workloads need stable versions, low latency, strict network boundaries, unusual hardware connections or operation during unreliable connectivity. The market moved from discrete releases to continuing obligations. A customer no longer evaluates only a copy of the code; it evaluates a provider’s ability to deliver access, protect information, support users and manage change. That matters because the practical cost of a bad supplier decision usually appears long after a contract has been signed.

Industrial systems, specialist engineering tools, regulated environments and long-lived equipment may require control over version timing that a continuously changing hosted service cannot offer without careful accommodation. Retail supply chains made revision slow by design. When software became network-delivered, the economics of a small fix changed. A vendor could issue it quickly, observe its effects and adjust again. That capacity is valuable, but it puts more importance on responsible control of the release process.

Local deployment can also simplify certain data-residency or integration requirements, though it does not eliminate legal or security obligations. A local server can be badly run; a cloud service can be carefully governed. Commercial attention moved from the next upgrade to the next renewal. Vendors now have reason to measure whether customers remain active, grow their use and receive enough value to continue. Those measures can improve product discipline, but they are not proof of customer benefit. A renewal driven by genuine utility is different from one driven by accumulated dependence.

The relevant distinction is not modern versus outdated. It is whether the work benefits from central operation or whether it needs a controlled environment that the customer can preserve and change on its own terms. A modern product is often an information system rather than a standalone program. Its operational value comes from connections that are easy to overlook during a feature demonstration. The right diligence asks where data travels, which identities govern it and which workflows would fail at short notice.

Subscription vendors increasingly recognise this spectrum through private-cloud, dedicated-hosting or hybrid offers. Those are not simply technical variations; they are commercial responses to customers who need different control boundaries. The risk is usually in the boundary between provider and customer. Security, resilience and cost control depend on both parties performing their respective tasks. A contract that is vague about that boundary invites failure at the moment a decision is most urgent.

Ask who carries each responsibility. Service quality is often most visible at the edge cases. A normal login, normal invoice and normal update reveal little. A departing employee, a contested bill, an integration failure or a request for a complete export reveals much more. Organisations should treat these moments as tests of the vendor relationship. The result should inform renewal decisions and internal controls, not disappear into one support ticket or one person’s memory.

Controls matter after deployment too. Where services contain personal or confidential information, data handling needs more than a generic assurance. The customer should know the relevant processing roles, retention choices, regional commitments, subcontracting arrangements and administrative controls. The exact legal analysis depends on jurisdiction and context, but the operational need for clear answers exists in every serious deployment.

Before a decision is locked in, create a short operating record. Name the business owner, the technical owner, the data involved, the identity route, the important integrations, the renewal date and the extraction route. None of this is bureaucratic decoration. It is the evidence needed to decide later whether the service still matches the work. A provider that welcomes those questions is more likely to be prepared for a mature relationship.

Keep local options where the operational case is strong. The software market has moved toward services, not toward one universal deployment pattern. Choose deliberate dependence over accidental lock-in. Every important system depends on somebody. The goal is to make the dependency proportionate to the value received, clear in contract and technical design, and recoverable if circumstances change.

Keep the decision grounded in a real operating scenario, such as a critical user leaving, a supplier incident, a price change or a request for complete records. Those scenarios convert abstract preference into testable responsibilities and expose the information that the customer will need under pressure.

Operational maturity appears in ordinary moments: a new employee joins, a customer asks for information, a password is lost, a budget is reduced or an integration is changed. A software model deserves confidence when those moments are understood rather than improvised.

Consolidation changed bargaining power

Subscriptions give large providers the chance to build broad suites around identity, storage, communication, analytics and business applications. Bundling can simplify procurement and reduce integration work, but it can also make one contract harder to leave. The commercial label hides an architectural decision. A perpetual licence and a subscription distribute control, operating work and financial exposure differently. The former tends to make a version durable on the customer side; the latter tends to make a service current on the provider side. Neither arrangement is automatically superior, because the workload and the customer’s capacity to govern it remain decisive.

Market concentration matters because a customer may become dependent not only on one tool but on a shared account layer and suite-wide data model. The more functions sit under one supplier, the greater the benefit of integration and the greater the impact of a dispute or outage. Distribution used to impose a hard rhythm on development. A release was expensive to manufacture and support, so feature groups often travelled together. Internet delivery reduced the cost of frequent revision and gave companies a route around retail intermediaries. It also made the supplier’s account system and service continuity part of the customer’s daily experience.

Large vendors publish financial evidence of the shift. Microsoft reported that Azure exceeded $75 billion in revenue in fiscal 2025, while Oracle reported $44.0 billion in fiscal 2025 cloud services and licence support revenue. These figures do not measure the whole market, but they show the scale of the commercial transition. Recurring revenue makes continuity commercially visible. The vendor must plan for service delivery across the term, while the customer must plan for repeated payment and renewal. The advantage is a closer alignment between use and payment; the risk is a closer alignment between dependence and pricing power.

Suite buying should not be rejected automatically. A common identity model, support channel and integration layer can be valuable. The buyer needs a reasoned view of which dependencies are acceptable and which deserve separation. The software cannot be separated cleanly from its surrounding service. Access rules, data retention, integrations and support routes determine what users can actually do. They also determine how a problem spreads when something changes or fails.

Competition can be preserved through open interfaces, export testing, contractual exit terms and avoiding unnecessary customisation that only one vendor can support. None of these steps guarantees easy migration, but each improves bargaining power. A good service relationship makes its limits visible. It explains what is managed centrally, what the customer must configure, how change is communicated and what happens in an incident. Hidden assumptions are more dangerous than imperfect technology.

Write down the real failure path. Evidence should be sought at the level of daily work. A service page or sales presentation is not enough when the product will hold records or coordinate a critical process. Ask to see the administrative view, the export function, the permission model and the process for reporting a fault. These details show whether the provider treats the customer as a partner in operations or as a passive user of an opaque system. They also reveal which skills the customer must retain.

Exit quality reveals real bargaining power. Metrics should be chosen carefully. Active seats, completed tasks, incident volume, time spent on manual work, support requests and export tests can all show whether a service is earning its cost. A dashboard of vanity usage figures is less helpful than a small set of measures tied to the business process the software was bought to improve.

An organisation should review the service at moments that reveal its true character: a material update, an incident, a price change, a major integration or an approaching renewal. These events create useful evidence about documentation, support, notice and recovery. They also reveal whether the supplier’s promises match the way the service behaves under pressure. A decision record prevents those lessons from being lost between teams.

Consolidation makes disciplined architecture more important. The stronger the suite, the stronger the need to know what would happen without it. The label is less useful than the operating facts. Buyers should choose the arrangement that makes important work dependable at a cost and level of control they can sustain. That may mean a subscription, a licence, a managed service or a hybrid of all three.

One clear owner, one current system record and one scheduled renewal review will prevent many avoidable surprises. The aim is informed control, not procedural theatre.

Review the commitment while alternatives remain practical.

AI features intensified the recurring model

Generative AI and advanced analytics have strengthened subscription logic because they often require hosted models, compute capacity, continuous safety work and rapid product updates. Their cost profile differs from a static desktop feature. The way software is sold now shapes the way it behaves in practice. A modern service may be easier to start, easier to update and easier to share, yet it is also usually more dependent on the supplier’s systems and terms. The buyer is therefore choosing both a tool and a continuing arrangement for running it.

Providers may include AI functions in a plan, impose usage limits or bill by consumption. Each method allocates uncertainty differently: a bundled feature spreads cost, while metering exposes the customer directly to changing use. Packaging did more than carry code. It forced a moment of commitment, from the supplier and from the buyer. Digital delivery made commitment more fluid: a trial could begin instantly, a feature could be enabled remotely and a plan could be changed without a new copy. The new flexibility depends on reliable identity, payment and support systems.

AI also increases the importance of data boundaries. A buyer needs to know what prompts, files and outputs are processed, whether they are retained, which model or subprocessor is involved and which controls the account administrator can set. A service company lives with its customers after the deal closes. That is a meaningful contrast with a pure one-time sale. The company continues to incur hosting, support and development costs, while customers continue to judge availability, change and usefulness. The relevant standard is whether the continuing charge corresponds to a continuing service.

Fast-moving AI features make change management harder. Product names, availability, pricing and model behaviour can change quickly, so procurement records and user guidance need periodic review rather than a one-time approval. The apparent simplicity of SaaS can hide complex dependencies. Shared data, account roles, automated actions and third-party connections become part of the same operating picture. Leaders should know which business processes rest on that picture and which contingency exists when a key part is unavailable.

The promise is not merely automation. In business tools, AI is often sold as a feature inside an existing subscription relationship, which deepens the role of the provider’s platform and data architecture. The benefits are real, but the risks have moved rather than vanished. Central release management can reduce local patching while increasing reliance on the supplier’s judgment and availability. Flexible pricing can make a service accessible while making long-term cost harder to see. The buyer needs evidence, not a broad promise of convenience.

A service must survive ordinary stress. The supplier’s incentives should be read through product behaviour. Does the service make it easy to remove unused users, retrieve records, understand changes and reduce a plan? Or does every route lead toward more commitment and less clarity? No single answer settles the question, but the pattern matters. Companies that expect to retain customers through ongoing value usually invest in making the relationship understandable, even when the customer chooses to buy less.

The service is more than the interface. Customers should also avoid a false comparison between a perfect local system and a flawed subscription. Local software brings its own risks: delayed patches, unsupported versions, weak backups, lost specialist knowledge and difficulty reaching distributed users. The issue is not which side has risks. It is whether the selected allocation of responsibility fits the people and processes that must carry it.

The best buyers avoid both extremes. They do not assume a subscription will remove all work, and they do not assume a local product will guarantee independence. They decide where responsibility should sit, document that choice and revisit it when the workload changes. Software is not static because the organisation using it is not static. A sound model has room for new needs without hiding new exposure.

Use AI services only where the value, data treatment, cost exposure and human review requirements are explicit. Novelty is not a sufficient operating case. The durable advantage is clarity. A buyer that understands the real operating model can accept useful dependence while avoiding needless fragility. That is a more durable position than a simple preference for boxes or subscriptions.

Keep the decision grounded in a real operating scenario, such as a critical user leaving, a supplier incident, a price change or a request for complete records. Those scenarios convert abstract preference into testable responsibilities and expose the information that the customer will need under pressure.

Consumer protection caught up with recurring billing

Recurring billing creates a consumer-protection issue because the costs of continuing are easy to overlook and the practical difficulty of ending the relationship can be greater than the effort of joining it. The old commercial boundary was tangible. It was a release, a licence key and often a physical object, so it was easy to imagine that the transaction had finished the relationship. The modern service exposes the continuing part: operating the product, changing it, securing it and keeping the account useful. That is more than a different payment schedule. It changes which party must act when the technology, the user base or the threat environment changes.

The EU Digital Content Directive governs certain consumer contracts for digital content and digital services and does not decide the legal nature of such contracts. Its focus on conformity and remedies reflects the fact that digital services continue to be supplied after purchase. Release timing followed the constraints of delivery. A vendor had to decide what was ready enough to ship and what could wait for a later version. Network channels weakened that discipline by making corrections, trials and plan changes available without a new retail run. The supplier could act more quickly, but customers also gained a product that could change underneath established routines.

In the United States, the Federal Trade Commission announced a final Click-to-Cancel rule in October 2024 aimed at making it easier for consumers to end recurring subscriptions and memberships. The legal and procedural status of specific rules can evolve, but the policy concern is clear. Revenue recognition reflects a delivery promise over time. That makes retention, expansion and support quality part of the supplier’s financial model, not merely after-sales concerns. It can fund steady product work and service operation, but it can also create pressure to raise switching costs. Buyers should distinguish a product that earns renewal from one that merely makes exit difficult.

Good subscription practice does not need dark patterns. Price, renewal timing, material terms and cancellation should be understandable before the customer commits. A business that depends on confusion is building fragile revenue. Software selection has become a question of operational design. The tool may be one component among accounts, permissions, databases, integrations and support processes. A useful inventory records each dependency before it becomes invisible through familiarity.

Consumer software suppliers should also be honest about post-cancellation effects. If projects, backups or high-value data will be deleted, reduced or made read-only, that consequence should be clear before sign-up. The customer still carries important responsibilities. A provider can operate infrastructure, but it cannot decide which employees should retain access, which data may be shared or what level of interruption the business can tolerate. Governance remains necessary, although its focus changes from installations to service oversight.

Test the operational claim directly. Migration deserves attention even when no change is planned. The customer does not need a complete replacement project on day one, but it should know whether data can be extracted, whether audit records and attachments travel with it, and which custom processes would need rebuilding. This knowledge improves negotiating leverage and makes a future change less traumatic. It also disciplines the design of the current implementation by discouraging undocumented shortcuts.

Context determines whether the trade works. Support quality often separates a service relationship from a simple licence. The customer needs to know who can open a case, what information will be available during an incident, which response commitments apply and how escalation works. A low-cost plan with no realistic support route may be appropriate for a low-consequence tool and wholly unsuitable for a service that holds critical records.

Practical diligence is modest but specific. Test one important workflow, inspect the administrator controls, read the change-notice process and ask for a realistic export example. A buyer does not need to predict every future event. It does need enough evidence to know where the service boundary sits and who will act when a problem crosses it. That preparation is cheaper before adoption than during a forced migration.

Make cancellation and data retrieval part of product design. Fairness at exit is one of the clearest signals of confidence in the service. A strong decision starts with the exit as well as the start. When teams understand cost, control, data and recovery before adoption, they are better able to use a service confidently and to challenge a renewal when terms no longer fit.

Keep the service boundary visible to the people who depend on it.

Financial predictability has limits

Subscriptions are often described as predictable for both vendor and buyer, but predictability depends on the contract and the workload. A fixed annual plan is different from a metered service with fluctuating consumption. Software stopped being judged only at the point of sale. A package once implied a relatively stable thing that a buyer could install and keep. Subscription delivery foregrounds the work that continues after purchase: access management, service operation, updates, support and retention of customer material. The commercial model matters because those duties do not disappear; they are reassigned, priced and governed in different ways.

For vendors, contracts can improve visibility into future revenue. Workday’s reporting describes subscription revenue backlog and the timing with which it expects portions to be recognised, illustrating how contracted service periods shape financial planning. The old release cycle was partly a logistics problem. Media, manuals, stock and channel relationships placed a premium on a version that could stand still for a while. Online delivery shifted the emphasis from manufacturing to version management, service availability and the design of a direct customer channel.

For buyers, predictable invoices are valuable only when seats, usage, renewals and price-change clauses are visible. An annual commitment can be easier to budget than irregular upgrade purchases, yet it can also lock in unused capacity. The financial model values relationships that persist. That can turn attention toward onboarding, prevention of incidents and practical customer success. It can also turn attention toward metrics that look healthy while hiding dissatisfied but trapped customers. Contracts, exports and support quality reveal which version a supplier is pursuing.

Finance teams should distinguish committed cost from expected cost and from maximum exposure under a usage model. This creates a more useful conversation than simply asking whether the service is OPEX or CAPEX. The running system is now the unit of analysis. A product that appears simple at the user level may connect to identity services, stored records, automations and administrative roles. Those links create value, but they also create consequences if a provider outage, account issue or contract termination interrupts access.

Price changes are not necessarily unfair; providers face costs and product changes too. The important question is whether the customer receives clear notice, a reasonable decision window and a credible option to reduce or leave. The risk is usually in the boundary between provider and customer. Security, resilience and cost control depend on both parties performing their respective tasks. A contract that is vague about that boundary invites failure at the moment a decision is most urgent.

Check the service at its edges. The long-term value of any software model is measured in recoverability. Can the organisation continue essential work during an outage? Can it understand the effect of an update? Can it obtain what it needs if the contract ends? These are not dramatic hypotheticals. They are ordinary management questions for services that hold valuable information and shape routine decisions. Clear answers make adoption safer and renewal more rational.

The operating detail decides the outcome. Ultimately, the useful discipline is to make assumptions testable. Record the expected users, the expected data, the expected workflow and the expected cost; then review them against actual use. This turns a subscription from an automatic recurring expense into an operating choice that can be improved, reduced, replaced or renewed with evidence.

Contracts should not be read only by procurement staff. The people responsible for security, records, finance and the business process should each test the terms that affect them. A good supplier relationship allows these questions to be answered plainly. It does not rely on the buyer discovering a limitation after data and users have become deeply embedded. Shared understanding is a form of resilience.

Build renewal and cost controls into normal operating calendars. A subscription budget should be actively managed, not merely paid. Use the commercial model as a design choice. A service can be the better answer where common operation and current access solve a real problem. A perpetual or self-managed option can be the better answer where stability, local authority or offline continuity dominate. The sound choice is the one whose trade-offs are explicit.

Before rollout, establish who approves new integrations, who reviews privileged accounts and who owns renewal evidence. These small controls protect against a common failure: a service spreading through normal work until no one can explain its commercial, security or continuity assumptions.

That discipline makes the later decision more factual and less hurried.

Review the commitment while alternatives remain practical.

Workload fit matters more than ideology

The best commercial model depends on the work. A static, specialist utility used offline has different needs from a shared service that must be accessible across locations, devices and teams. The decisive change was in the relationship, not in the checkout page. A boxed purchase put emphasis on possession of a copy and a defined version. A subscription brings a continuing promise of access to a service that the supplier operates. The buyer therefore needs to consider the service’s behaviour over time, including its release cadence, account controls, data handling and path out.

Hosted subscriptions fit work that benefits from common data, central updates, flexible access, managed capacity and ongoing feature development. They fit poorly when a service requires strict isolation, unusual local hardware or frozen behaviour. Physical media made software feel more self-contained than it usually was. Updates, support and compatibility still existed, but they were less visible in the commercial story. Direct digital delivery brought those activities closer to the product and made them available on a much shorter cycle.

Perpetual and self-managed options fit work that values independence, long support horizons and customer-controlled timing. They fit poorly when the customer lacks the staff or process needed to patch, support and secure the system. Recurring income changes the decisions inside a software company. Product teams, account teams and finance functions all gain reason to care about the life of the relationship. That can produce better service. It can also produce excessive tiering, opaque bundles and a habit of treating cancellation friction as a commercial asset.

Eurostat reported that 52.74% of EU enterprises used paid cloud computing services in 2025, with email, office software and file storage among the most-used categories. The pattern shows broad adoption, not a rule that every workload belongs in the cloud. The operational dependency is usually broader than the visible feature set. A customer may be choosing an account structure, a storage location, a logging model and a chain of integrations as well as an interface. Before adoption, teams should identify what work stops if access fails, which data becomes unavailable and which internal controls rely on the service.

Selection should start with a workload statement: users, data, availability need, latency, integration, compliance, change tolerance and the realistic ability to operate the tool. Pricing follows from those facts. A good service relationship makes its limits visible. It explains what is managed centrally, what the customer must configure, how change is communicated and what happens in an incident. Hidden assumptions are more dangerous than imperfect technology.

Evidence beats a feature-list promise. Pricing deserves the same scrutiny as architecture. The buyer should identify the unit that causes a bill to rise, the person who monitors that unit, and the action available when usage moves beyond plan. This is especially important for services that price storage, transactions or advanced computing. A price model can be sensible and still become risky when its measurement is invisible to the people responsible for the budget.

A clean contract needs usable practice. An implementation plan should preserve an independent record of important decisions. Keep copies of configuration choices, integration mappings, user roles, data categories and contract commitments in places the supplier does not control. This does not create independence from the service, but it makes the customer less dependent on memory and more able to assess a problem or a future transition.

Service providers benefit from the same clarity. They can state which functions they operate, which customer responsibilities remain, which limits apply and how a customer can prepare for change. Clear boundaries reduce support disputes and help customers see the continuing value of the service. Ambiguity may accelerate a sale, but it weakens renewal confidence and makes every incident harder to resolve.

Choose the model that reduces the total burden of delivering reliable work. The correct answer may be cloud, local, open source, managed service or a deliberate combination. The next renewal should never be the first serious review. Sound selection creates a record of assumptions, owners and export needs at the start. That record makes the later decision calmer, more factual and less vulnerable to pressure.

Do not confuse faster deployment with lower complexity. The complexity may simply move into identity configuration, data ownership, user training and supplier management. A short implementation can still create a long relationship, which is why the design choices deserve a durable written record.

Clear records keep technical, commercial and business assumptions connected.

Test one important assumption before it becomes an expensive surprise.

Supplier obligations are now more visible

When software is sold as a continuing service, customers reasonably expect continuing obligations: availability, security maintenance, support, transparent change, protection of customer data and a workable exit route. A software purchase is now often a live operating arrangement. The shift is visible in recurring invoices, but the deeper change is technical and organisational. Code, data, identity, support and release management are joined together in a service that must keep functioning after the original procurement decision. The question for buyers is not just what feature is present today, but which obligations persist tomorrow.

A provider cannot promise zero outages or unlimited compatibility. It can state boundaries honestly, publish service information, communicate incidents, maintain documentation and avoid making critical controls inaccessible without notice. The delivery channel influenced the product itself. Packaging, distribution and installation requirements encouraged large, visible releases. Once the network became the normal path, a supplier could publish smaller changes, revise documentation and serve a user directly. Faster delivery is useful only when customers can see what changed and prepare where preparation is needed.

Security guidance increasingly frames suppliers as responsible for reducing avoidable customer burden. CISA’s secure-by-design work asks technology manufacturers to take ownership of security outcomes rather than leaving customers to absorb preventable risks. The supplier’s success became tied to continued use. A major subscription business cannot rely solely on a launch peak; it has to maintain a service customers regard as worth renewing. The healthier version of that incentive rewards reliability, adoption and clear support. The darker version uses complex packaging or hard-to-move data to delay cancellation.

Transparency also has a commercial value. A buyer can plan around a documented maintenance window, API deprecation or storage limit. It cannot plan around a surprise that arrives after a dependency has become critical. A subscription service carries a hidden map of dependencies. It includes people, permissions, data, vendors and automated processes. Making that map explicit before rollout is a practical way to reduce surprise later.

Suppliers should keep the contract, operational documentation and actual service behaviour aligned. A strong status page cannot compensate for an export process that fails when customers need it. The benefits are real, but the risks have moved rather than vanished. Central release management can reduce local patching while increasing reliance on the supplier’s judgment and availability. Flexible pricing can make a service accessible while making long-term cost harder to see. The buyer needs evidence, not a broad promise of convenience.

Make the hidden dependencies visible. Useful comparisons look beyond feature lists. Two tools may both claim collaboration, security or automation, while assigning very different responsibilities for permissions, storage, integration recovery and support. The buyer should write down the precise workflow that matters, then test each candidate against it. A tool that wins a broad feature comparison can still lose when measured against the one process that must remain reliable during absence, growth or disruption.

Independence is measured in recovery. The right level of customisation deserves restraint. A service may offer scripting, low-code workflows and extensive integrations, but every local adaptation creates a maintenance burden and can raise the future cost of switching. Customisation should be reserved for work that genuinely distinguishes the organisation or meets a real control need, not for recreating every historical preference.

Good governance starts with a basic distinction between reversible and hard-to-reverse choices. A plan tier or seat count can often be changed. A platform that holds records, automations and working habits cannot. Put more research into the decision that is difficult to unwind, and retain enough internal knowledge to challenge a renewal rather than simply accepting the default path. That is a commercial discipline as well as a technical one.

Earn renewal by making the relationship legible. The customer should know what the service does, who is responsible for which controls and what happens if either party leaves. The practical test is whether responsibility is visible and manageable. A contract is not a substitute for an operating plan, and a perpetual licence is not a substitute for maintenance capability. Match the model to the work rather than forcing the work into a fashionable pricing structure.

Keep the decision grounded in a real operating scenario, such as a critical user leaving, a supplier incident, a price change or a request for complete records. Those scenarios convert abstract preference into testable responsibilities and expose the information that the customer will need under pressure.

Test one important assumption before it becomes an expensive surprise.

The market now sells a continuing relationship

The move from boxed versions to subscriptions changed software from a product purchased at intervals into an operational relationship that is tested every day. The change was enabled by network delivery, cloud operation, account systems and the commercial appeal of recurring revenue. The box concealed the amount of ongoing work behind a single sale. The service model makes that work visible because someone must operate the environment, handle new risks, respond to customer needs and keep the product compatible with the world around it. A good analysis tracks where those tasks move, who pays for them and what happens when the supplier changes course.

It also reflected a genuine shift in user expectations. Teams increasingly want shared files, current features, remote access and reduced local infrastructure work. Providers increasingly want closer customer relationships and more visible demand. What looked like a product calendar was also a distribution calendar. Once that calendar loosened, product teams could respond more quickly to failures and customer signals. They could also change more often than customers expected. That is why operational notice and release documentation became more valuable, not less.

Eurostat’s 2025 data show paid cloud use across more than half of EU enterprises, and large software providers report substantial cloud or subscription revenue. The movement is real and durable, but its benefits are conditional rather than automatic. The invoice is now an ongoing referendum on the product. Customers may renew because the service works, because their organisation is deeply integrated or because leaving feels too costly. These motives should not be conflated. A strong buyer asks whether the provider’s commercial model gives it reason to improve the service or merely reason to make the service sticky.

Subscriptions work best when the service contains recurring value and the supplier accepts the obligations that follow: clear terms, service continuity, security work, useful support and honest exit mechanisms. The account has become as important as the installed code. A buyer should examine administration, recovery, records and integration ownership alongside the user experience. Those details decide whether the service remains usable under pressure.

Boxed and perpetual products still have a place where local control, stable versions or offline use matter more than central operation. The market did not erase them; it made the choice more explicitly tied to operating needs. The customer still carries important responsibilities. A provider can operate infrastructure, but it cannot decide which employees should retain access, which data may be shared or what level of interruption the business can tolerate. Governance remains necessary, although its focus changes from installations to service oversight.

Test the workflow under pressure. Different stakeholders see different costs. Finance sees committed and variable spend. Security sees identity, logging and incident exposure. Legal sees terms, processing and responsibility. Users see whether the work is easier or harder. A decision that ignores one of these views often creates a later conflict. The purpose of cross-functional review is not to slow every purchase; it is to identify the dependencies that deserve a deliberate owner.

Cost depends on the whole system. History gives the comparison some humility. Maintenance agreements, hosted applications and time-limited rights existed before the current SaaS market. The newer model became dominant where broadband, web standards, cloud infrastructure and account-based delivery made the continuous service easier to operate and easier to sell. The relevant change is cumulative: technology, finance and user expectations reinforced one another.

Customer control does not require total technical ownership. It requires enough information and ability to make informed choices: who can access the service, what data can leave it, what changes are planned, what the bill measures and what happens at termination. Those are ordinary requirements for a dependable operating relationship. They become especially important when the service supports revenue, compliance or core records.

Software buyers should stop asking only whether they prefer ownership or subscription. The stronger question is which relationship lets them do important work with acceptable cost, control and reversibility. The decision should be made before dependence accumulates. The appropriate model follows the workload, the organisation’s capacity to operate technology and the consequences of interruption. A recurring service is valuable when its continuous work is real and visible. A local licence remains defensible when independence and timing control matter more.

Supplier choices become customer risks when they affect access, price, security or compatibility. That is why a vendor’s change process belongs in due diligence. The customer needs advance information and a realistic way to assess material consequences before routine work is disrupted.

Questions buyers ask about the subscription software market

Author:
Jan Bielik
CEO & Founder of Webiano Digital & Marketing Agency

This article is an original analysis supported by the sources cited below

SP 800-145, The NIST Definition of Cloud Computing
NIST’s definition of cloud computing, including on-demand network access, pooled resources and service models.

Guidelines on Security and Privacy in Public Cloud Computing
NIST guidance on security and privacy considerations for public cloud use.

General Access Control Guidance for Cloud Systems
NIST guidance on access-control considerations for cloud systems.

Secure by Demand Guide
CISA guidance for customers seeking more secure technology products and services.

Secure by Design
CISA material on supplier responsibility for secure technology outcomes.

Regulation (EU) 2016/679
The General Data Protection Regulation, including the legal framework relevant to personal-data portability.

Regulation (EU) 2023/2854
The EU Data Act, including provisions on switching between data-processing services.

Data Act
European Commission implementation information on the Data Act and its application date.

Directive (EU) 2019/770
EU rules on certain consumer contracts for digital content and digital services.

Regulation (EU) 2022/2554
The Digital Operational Resilience Act for the financial sector.

Cloud computing statistics on the use by enterprises
Eurostat data on enterprise use of paid cloud computing services in the EU.

Salesforce 2025 Form 10-K
Salesforce reporting on subscription and support revenue and its cloud-services model.

Adobe 2025 Form 10-K
Adobe reporting on subscription revenue and recurring-revenue performance.

Workday 2025 Form 10-K
Workday reporting on subscription services revenue, delivery costs and backlog.

Microsoft 2025 Annual Report
Microsoft reporting on cloud and commercial software performance.

Oracle fiscal 2025 results
Oracle reporting on cloud services and licence-support revenue.

SAP 2025 financial data
SAP’s reported cloud, software and support revenue figures.

ServiceNow 2025 Form 10-K
ServiceNow reporting on subscription revenue and the costs of operating subscription services.

Zoom 2026 Form 10-K
Zoom reporting that its revenue is driven by subscriptions to its workplace and business services.

Atlassian 2025 Form 10-K
Atlassian reporting on cloud and data-centre migrations and its cloud strategy.

FTC final Click-to-Cancel rule announcement
FTC announcement concerning cancellation of recurring subscriptions and memberships.

European Commission cloud computing policy
European Commission explanation of Data Act objectives related to cloud switching and vendor lock-in.