A SaaS agreement signed on a sales demo becomes an architecture failure when auto-renewal and weak exit terms make switching cost exceed contract value.
DPDPA 2023 creates mandatory data processing obligations in every SaaS agreement involving personal data
A SaaS agreement governs a fundamentally different relationship than a traditional software licence. In a licence, the customer acquires a right to use a copy of the software, typically installed on their own infrastructure. In SaaS, the customer accesses functionality delivered over the internet. The customer never possesses the software. The provider maintains the infrastructure, deploys updates, manages security, and controls access.
This structural difference creates five contractual concerns that do not exist in traditional licensing: (1) continuous dependency, the customer cannot operate without the provider's infrastructure being available; (2) data custody, the customer's data resides on the provider's servers; (3) unilateral change, the provider can modify the platform without the customer's agreement; (4) exit difficulty, switching SaaS providers requires data migration, integration rebuilding, and user retraining; and (5) multi-tenancy risk, the customer's data shares infrastructure with other customers.
Under the Indian Contract Act 1872, a SaaS agreement is a service contract, not a transfer of property rights. This classification affects GST treatment (18% on services vs. potential equalisation levy considerations for cross-border SaaS), withholding tax obligations (no royalty characterisation for pure SaaS, though the distinction is contested in certain treaty contexts), and termination consequences (the customer loses all access upon termination, unlike a perpetual licence where the licensed copy remains).
The SaaS agreement must be drafted with these structural realities in mind. A licence agreement template repurposed for SaaS will fail to address data governance, service continuity, platform changes, and the exit problem that define the SaaS relationship.
The subscription scope defines the boundary of the SaaS relationship. Everything within scope is the provider's obligation. Everything outside scope is either excluded or subject to additional fees. Ambiguity in scope is the root cause of most SaaS disputes.
Module and Feature Definition: The agreement should specify exactly which SaaS modules, features, and tiers are included in the subscription. Feature lists evolve, the agreement should reference the feature set as of the subscription effective date and address how subsequent feature additions and deprecations are handled. A general reference to "the SaaS platform" without feature specificity creates disputes when the provider claims a requested capability is an add-on rather than a core feature.
User and Usage Limits: Per-user SaaS should define what constitutes a user (named user vs. concurrent user), whether users can be reassigned, the minimum commitment (if any), and the process for adding or removing users mid-term. Usage-based SaaS should define the metered unit (API calls, transactions, storage, compute time), the measurement methodology, usage alerts and caps, and overage pricing. The agreement should specify whether unused allocation rolls over or expires at period-end.
Customisation and Configuration: SaaS platforms offer varying degrees of customisation. The agreement should distinguish between: configuration (using the platform's built-in settings to tailor behaviour, included in the subscription), customisation (modifying or extending the platform code or creating bespoke features, typically additional scope), and integration (connecting the SaaS platform with the customer's other systems, may be included or additional depending on complexity). Ownership of customisations is particularly contentious, the provider wants to incorporate useful customisations into the platform for all customers; the customer who paid for the customisation wants exclusivity or at least a fee reduction.
Support and Maintenance: The agreement should define the support included in the subscription: support hours, support channels (email, phone, chat, dedicated account manager), response time commitments by severity level, and the escalation process. Premium support tiers should be separately priced and documented. The provider's obligation to maintain the platform, deploy security patches, and release updates should be specified, including whether major version upgrades are included in the subscription or priced separately.
The SLA is the mechanism that converts the provider's service promises into measurable, enforceable commitments. Without an SLA, the customer has no contractual basis for claiming that the service was inadequate, no matter how poor the performance.
Uptime Commitment: Uptime is measured as a percentage of total available minutes in the measurement period, excluding scheduled maintenance. The industry tiers: 99.9% (8.76 hours downtime per year, enterprise standard), 99.95% (4.38 hours, premium tier), 99.99% (52.6 minutes, mission-critical). The SLA must define what constitutes downtime: is the service "down" only when completely inaccessible, or also when response times exceed specified thresholds? The measurement period matters: monthly measurement allows 43 minutes of downtime at 99.9%, while annual measurement allows the same total but permits clustering of downtime in a single incident.
Exclusions: Standard exclusions from uptime calculation include: scheduled maintenance (notified at least 72 hours in advance, conducted during off-peak hours), downtime caused by the customer's network or systems, force majeure events, third-party service failures outside the provider's control, and government-ordered shutdowns. Each exclusion should be narrowly defined to prevent the provider from attributing all downtime to excluded causes.
Service Credits: Service credits are the contractual remedy for SLA breaches. The standard structure credits a percentage of the monthly fee for each defined shortfall: 10% credit for uptime between 99.0% and 99.9%, 25% credit for uptime between 95.0% and 99.0%, 50% credit for uptime below 95.0%. Credits are applied against future invoices, not refunded in cash. The maximum credit per period is typically capped at 30% of monthly fees. The customer must claim credits within a specified period (typically 30 days) with supporting documentation.
Termination Right for Persistent Failure: Service credits alone are an inadequate remedy if the platform is consistently underperforming. The SLA should include a termination trigger: if uptime falls below a specified threshold (for example, 95%) for three consecutive months or any single month below 90%, the customer has the right to terminate without penalty and receive a pro-rata refund of prepaid fees. This termination right is the real enforcement mechanism, without it, the provider's maximum exposure is capped at service credits, which may be commercially insignificant relative to the customer's losses from service failure.
Data governance is the defining challenge of SaaS procurement. The customer's most valuable asset, their data, resides on infrastructure controlled by a third party. The SaaS agreement must establish clear rules for who owns the data, where it is stored, how it is protected, and what happens to it when the relationship ends.
Data Ownership: The agreement should unambiguously state that all data uploaded by the customer, generated through the customer's use of the platform, and derived from the customer's data belongs to the customer. The provider has no ownership interest in customer data and may not use, disclose, or analyse customer data except as instructed by the customer or as necessary to provide the service. The contentious area is aggregated and anonymised data: the provider typically seeks the right to use such data for product improvement and industry benchmarking. If granted, the anonymisation standard must be specified to prevent re-identification risk.
Data Residency and Localisation: The agreement should specify the data centre locations where customer data will be stored (primary and disaster recovery). For Indian customers, multiple regulatory requirements apply: DPDPA 2023 will restrict transfers to jurisdictions notified by the Central Government; RBI mandates that payment system data must be stored exclusively in India; sector-specific regulators (IRDAI, SEBI) have their own data localisation requirements. The agreement should include: the current data centre locations, the provider's obligation to notify changes with 90 days advance notice, the customer's right to require India-only storage, and a migration plan if a permitted jurisdiction becomes restricted.
DPDPA Compliance: A Data Processing Agreement should be appended as a schedule, covering: processing instructions, categories of personal data and data principals, security measures (encryption standards, access controls, audit logging, vulnerability management), sub-processor engagement protocol (prior written approval, flow-down of obligations, current sub-processor list), data breach notification (within 72 hours to the customer, who then notifies the Data Protection Board), data retention and erasure (upon purpose fulfilment or contract termination), Data Principal rights facilitation (the provider assists the customer in responding to access, correction, and erasure requests), and audit rights (the customer or its designated auditor can verify compliance with the DPA).
Security Obligations: The SaaS agreement should require: SOC 2 Type II or ISO 27001 certification maintained throughout the subscription, annual penetration testing by an independent firm with summary results shared with the customer, encryption of data at rest (AES-256) and in transit (TLS 1.2+), multi-factor authentication for administrative access, role-based access controls, audit logging with 12-month retention, incident response plan with defined escalation procedures, and compliance with CERT-In reporting requirements under the Information Technology Act 2000.
SaaS pricing is not a one-time negotiation. It is an ongoing commercial relationship governed by the pricing model, escalation mechanics, and renewal terms. The agreement must address all three dimensions to prevent economic lock-in.
Pricing Models: Per-user (fixed fee per named or concurrent user per period, simple but can become expensive at scale), per-usage (metered charges based on transactions, API calls, storage, or compute, aligns cost with value but creates budget unpredictability), tiered (feature-based packaging with ascending price points, encourages upselling), and flat-rate (unlimited users and usage for a fixed fee, simple but typically includes fair-use caps). The agreement should specify which model applies, the unit of measurement, the billing frequency, and the mechanism for adjusting the pricing model at renewal if the customer's usage profile changes.
Price Escalation Caps: SaaS subscriptions typically auto-renew with annual price increases. Without a contractual cap, the provider can increase prices by any amount at renewal, exploiting the switching costs that make it impractical for the customer to move. The agreement should cap annual price increases at a defined percentage: typically 5-7% or CPI (Consumer Price Index) plus a margin, whichever is lower. Multi-year commitments should lock in pricing for the commitment period with escalation applying only at the end of the committed term.
Auto-Renewal Terms: Auto-renewal is standard in SaaS. The agreement should specify: the renewal term (typically 12 months), the cancellation notice period (30-60 days before the renewal date), the method of providing cancellation notice (written notice to a specified address or email, not buried in a portal setting), the consequence of failing to cancel (automatic renewal at the escalated price), and the customer's right to downgrade at renewal. The provider should be required to send a renewal reminder at least 60 days before the renewal date, specifying the renewal price and any changes to terms.
Mid-Term Adjustments: The agreement should specify the process for adding users or modules mid-term (immediate activation, pro-rata billing for the remainder of the current term), removing users or modules mid-term (typically effective at the next renewal, not during the current term, this is a common trap), and upgrading or downgrading tiers (upgrade effective immediately with price adjustment, downgrade effective at renewal). The agreement should also address what happens if the customer exceeds usage limits: automatic overage charges, throttling, or service suspension.
In a SaaS relationship, the IP landscape is structurally different from traditional software licensing. The customer never receives the software code. The provider retains full ownership of the platform. The agreement must delineate the boundary between provider IP, customer data, and the grey area of customisations and configurations.
Provider Platform IP: The SaaS platform, source code, object code, algorithms, user interface, APIs, documentation, and all underlying technology, belongs to the provider. The customer receives a non-exclusive, non-transferable, non-sublicensable right to access and use the platform during the subscription term for the customer's internal business purposes. This right terminates immediately upon expiry or termination of the subscription.
Customer Data and Content: All data uploaded by the customer, generated through the customer's use of the platform, and derived from the customer's data belongs to the customer. The provider is granted a limited licence to host, process, and display the customer's data solely for the purpose of providing the service. This licence terminates upon subscription termination, after which the provider must return and delete the data as specified in the exit provisions.
Customisation Ownership: Customisations are the contested territory. If the customer pays for bespoke development, new modules, modified workflows, custom integrations, who owns the resulting code? Three positions: (1) the customer owns the customisation code and grants the provider a licence to host it on the platform, (2) the provider owns the code and grants the customer a perpetual licence to use it, or (3) the provider owns the code and includes it in the subscription with no separate licence. Position (1) is strongest for the customer but creates complexity if the customisation is integrated into the platform codebase. Position (2) is the most common compromise. The agreement should also address whether the provider can incorporate the customisation concepts into the platform for all customers.
Configuration as Customer IP: Configurations, the settings, workflows, templates, and rules the customer creates using the platform's built-in tools, should be treated as customer IP because they reflect the customer's business logic and operational knowledge. The agreement should ensure that configurations can be exported in a usable format and that the provider does not use or disclose them to other customers.
The exit from a SaaS relationship is the moment when the vendor lock-in risk materialises. The customer must migrate data, rebuild integrations, retrain users, and maintain business continuity throughout the transition. The SaaS agreement must address each dimension of exit.
Data Export: The provider must export all customer data in industry-standard formats (CSV, JSON, XML, or as agreed) within a specified period after termination notice. The export should include all data categories: transactional records, configuration data, user data, audit logs, and any derived data the customer is entitled to. The agreement should specify the export format for each data category, the timeline for completing the export (typically 30-60 days), and the charges (if any) for the export service.
Transition Assistance Period: After termination, the customer needs time to migrate to an alternative platform. The agreement should provide a transition assistance period of 90-180 days during which the customer retains read-only access to the platform for data verification and the provider provides reasonable cooperation with the replacement provider. Transition assistance should be available at the provider's then-current professional services rates or at the rates specified in the agreement.
Data Destruction: After the data export period and transition assistance period, the provider must permanently delete all customer data from primary systems, backup systems, disaster recovery sites, and any sub-processor systems. The provider should issue a written certification of data destruction signed by an authorised officer. Under DPDPA, this is not merely a contractual obligation, failure to erase personal data after purpose fulfilment is a statutory violation.
API and Integration Documentation: During the subscription term, the provider should maintain and provide API documentation that enables the customer to build integrations. Upon termination, the customer should have the right to retain API documentation for the purpose of migrating integrations to an alternative platform. The agreement should specify that API documentation is not confidential information of the provider for this limited purpose.
SaaS liability structures must account for the unique risk profile of the relationship: the customer's data is in the provider's custody, the customer's business operations depend on the provider's infrastructure, and the provider's platform is accessible to all customers simultaneously, meaning a vulnerability affects everyone.
Tiered Liability Caps: General liability (service failures, non-performance): capped at 12 months of fees paid or payable. Elevated liability (data breaches, confidentiality violations, IP infringement): capped at 2-3x the general cap. Uncapped: fraud, wilful misconduct, and DPDPA penalties imposed by the Data Protection Board. The customer should resist a single aggregate cap that conflates service failures with data breaches, the risk profile is fundamentally different.
Data Breach Indemnification: The provider should indemnify the customer against losses arising from data breaches caused by the provider's failure to implement the agreed security measures. The indemnification should cover: notification costs to affected data principals, credit monitoring services (if applicable), regulatory fines imposed on the customer as Data Fiduciary (to the extent caused by the provider's failure), forensic investigation costs, and legal costs. DPDPA penalties for failure to implement reasonable security safeguards can reach ₹250 crore, the indemnification cap must be adequate to address this exposure.
IP Indemnification: The provider should indemnify the customer against third-party claims that the SaaS platform infringes intellectual property rights. This is critical because the customer has no visibility into the platform's codebase and cannot assess infringement risk independently. The indemnification should include the provider's obligation to: defend the claim at its expense, pay any damages or settlement, and if the platform is found to infringe, either procure the right for the customer to continue using the platform, modify the platform to be non-infringing, or terminate the subscription and refund prepaid fees.
Consequential Damages: Most SaaS agreements exclude consequential damages. However, for enterprise SaaS that is integrated into the customer's core business operations, the most significant losses from platform failure are consequential: lost revenue, lost customers, regulatory penalties, and business disruption. The customer should negotiate carve-outs for foreseeable consequential losses directly linked to specific provider failures: data breach, prolonged outage exceeding the SLA termination threshold, and wrongful termination of the subscription.
SaaS procurement in India must navigate a multi-layered regulatory environment. The agreement must allocate compliance obligations between the customer and provider for each applicable regulation.
DPDPA 2023: The customer is the Data Fiduciary. The provider is the Data Processor. The customer bears primary responsibility for obtaining consent, defining processing purposes, and responding to Data Principal rights requests. The provider must process data only as instructed, implement reasonable security safeguards, notify breaches within 72 hours, and not engage sub-processors without prior approval. The agreement should clearly map each DPDPA obligation to the responsible party.
Information Technology Act 2000: The IT Act and associated rules impose obligations on intermediaries and service providers. CERT-In directions (April 2022) require reporting of cybersecurity incidents within 6 hours of becoming aware, maintaining logs for 180 days, and synchronising system clocks with NTP servers. The SaaS provider must comply with these requirements for its infrastructure and cooperate with the customer's compliance obligations. The agreement should specify the provider's CERT-In reporting obligations and the process for coordinating incident response between the customer and provider.
RBI for Financial Services SaaS: SaaS platforms used by banks, NBFCs, and payment system operators must comply with RBI outsourcing guidelines, data localisation requirements, and vendor risk management frameworks. The agreement must include: the right of RBI to access the provider's premises, audit rights, business continuity requirements, and the provider's obligation to maintain operations in India even if the provider's global operations are disrupted.
GST Treatment: SaaS provided by an Indian provider to an Indian customer attracts 18% GST. Cross-border SaaS raises complex questions: SaaS provided by a foreign provider to an Indian customer may attract GST under reverse charge mechanism, and the customer must self-assess and pay. The agreement should specify which party bears the GST obligation, whether the stated fees are inclusive or exclusive of GST, and the process for handling changes in tax treatment.
SaaS platforms are living systems. The provider continuously updates the platform, adding features, modifying interfaces, updating APIs, and deprecating legacy capabilities. The customer chose the platform for its current feature set. Uncontrolled changes can disrupt the customer's operations.
Change Notification: The agreement should require the provider to notify customers of material platform changes: new features (30 days advance notice), interface changes (60 days), API changes (90 days, with backward compatibility for 12-24 months), feature deprecation (90-180 days), and security-related emergency changes (as soon as practicable). The notification should specify the nature of the change, the timeline, the impact on existing functionality, and any required customer action.
Backward Compatibility: For enterprises that have built integrations using the SaaS platform's APIs, backward compatibility is operationally critical. The agreement should require the provider to maintain backward compatibility for the current API version for at least 12 months after releasing a new version, provide migration tools and documentation for API transitions, and offer a sandbox environment for customers to test integrations against new API versions before production deployment.
Feature Deprecation Rights: If the provider deprecates a feature that was a material reason for the customer's subscription decision, the customer should have the right to: require the provider to maintain the feature for a defined transition period (typically 12 months), negotiate a replacement feature or workflow, or terminate the subscription without penalty if no adequate replacement is provided. This right prevents the provider from effectively changing the product the customer purchased.
Customer-Initiated Change Requests: The agreement should include a mechanism for the customer to request enhancements: the process for submitting requests, the provider's obligation to evaluate and respond, and the commercial terms for implementing customer-specific enhancements (whether included in the subscription or separately priced).
SaaS disputes typically involve technical complexity: was the platform actually down or was the customer's network at fault? Did the provider's security failure cause the data breach or was the customer's credential management the root cause? The dispute resolution mechanism must be designed to handle technical fact-finding efficiently.
Technical Expert Determination: For SLA disputes and technical performance disagreements, the agreement should include a technical expert determination mechanism before escalating to arbitration. An independent technical expert, agreed by both parties, reviews the monitoring data, system logs, and technical evidence to determine whether the SLA was breached. The expert's determination is binding on both parties for factual matters and reduces the time and cost of formal dispute resolution.
Tiered Escalation: Tier 1, Account manager and customer IT lead within 10 business days. Tier 2, Senior management of both parties within 20 business days. Tier 3, Mediation under the Mediation Act 2023. Tier 4, Arbitration under the Arbitration and Conciliation Act 1996. Most SaaS disputes involve ongoing relationships, mediation preserves the relationship while providing a structured forum for resolution.
Arbitration: The agreement should specify: seat (Mumbai, New Delhi, or Bengaluru are typical for technology disputes), rules (MCIA for domestic, SIAC for cross-border), sole arbitrator for disputes below ₹5 crore, three-member tribunal for larger disputes, language (English), and timeline (12 months for the award). For SaaS agreements with foreign providers, the governing law and seat selection become particularly important, Indian customers should prefer an Indian seat to benefit from the supervisory jurisdiction of Indian courts.
Governing Law: Indian law governs for domestic SaaS. For cross-border SaaS, the foreign provider typically proposes their home jurisdiction's law. The customer should negotiate for Indian law for data protection matters (DPDPA compliance obligations) and the provider's home jurisdiction law for platform IP matters, with Indian arbitration seat. This split-law approach is increasingly common in cross-border technology agreements.
Short, direct, on the record.
A SaaS Agreement is a contract governing the provision of software as a service, the customer accesses the software over the internet on a subscription basis without installing, downloading, or owning the software. Under Indian law, a SaaS agreement is treated as a service contract governed by the Indian Contract Act 1872, not a software licence. This distinction matters for tax treatment (GST on services vs. royalty withholding on licences), IP ownership (no transfer of software rights to the customer), and termination consequences (the customer loses access entirely upon termination, unlike a perpetual licence). The agreement defines subscription scope, service levels, data handling obligations, customisation rights, security standards, and exit provisions.
SaaS SLAs should define uptime as a percentage of total available minutes in the measurement period (monthly is standard), excluding scheduled maintenance windows notified in advance. Industry standard commitments are 99.9% (8.76 hours downtime per year) for enterprise SaaS and 99.5% for standard tiers. The SLA should specify: the measurement methodology and monitoring tools, exclusions from uptime calculation (scheduled maintenance, force majeure, customer network issues, third-party dependency failures), service credit calculation for SLA breaches (typically 10% of monthly fees for each 0.1% below the committed level), the claim process and documentation requirements, maximum service credit per period (typically capped at 30% of monthly fees), and the right to terminate for persistent SLA failure (typically 3 consecutive months below the committed level).
If the SaaS platform processes personal data of Indian data principals, the agreement must comply with DPDPA 2023. The customer (Data Fiduciary) must ensure the SaaS provider (Data Processor) implements reasonable security safeguards proportionate to the data sensitivity, processes data only according to documented instructions, does not engage sub-processors without prior written approval and flow-down of obligations, notifies data breaches within 72 hours, assists with Data Principal rights requests (access, correction, erasure), and erases or returns personal data upon termination. A Data Processing Agreement should be annexed as a schedule specifying the data categories, processing activities, security measures (encryption at rest and in transit, access controls, audit logging), and the audit rights of the customer.
Vendor lock-in is the most underestimated risk in SaaS procurement. It manifests when: (1) data is stored in proprietary formats without export capability, (2) the customer builds business-critical workflows on provider-specific features with no equivalent in alternative platforms, (3) custom integrations use proprietary APIs that cannot be replicated, (4) historical data including transactional records, audit logs, and analytics cannot be extracted in usable formats, and (5) the contract auto-renews with narrow cancellation windows. Mitigation requires: contractual data export in open standard formats (CSV, JSON, XML), API documentation and access rights that survive termination, a transition assistance period of 90-180 days after termination, the right to retain read-only access during transition, and price escalation caps that prevent economic lock-in through aggressive renewal pricing.
Data residency specifies where customer data is physically stored and processed. For Indian customers, multiple regulatory layers apply: DPDPA 2023 may restrict transfers to jurisdictions notified by the Central Government, RBI mandates that payment system data must be stored in India (April 2018 circular), IRDAI requires insurance data localisation, and SEBI has data storage requirements for market intermediaries. The SaaS agreement should specify the primary and backup data centre locations, the provider obligation to notify any change in storage location with 90 days advance notice, the migration plan if a currently permitted jurisdiction becomes restricted, and the customer right to require India-only storage at any time. For multi-tenant SaaS, data isolation controls must ensure that Indian customer data is not inadvertently replicated to restricted jurisdictions.
The customer owns all data uploaded to, generated by, or derived from the SaaS platform in the course of the customer use. This includes input data, output data, metadata, configurations, customisations created by the customer, and any data generated through the customer use of the platform. The SaaS provider retains ownership of the platform IP: the software code, algorithms, user interface, documentation, and generic improvements. The contentious area is aggregated and anonymised data, the provider typically seeks the right to use anonymised, aggregated customer data for product improvement and benchmarking. The SaaS agreement should specify whether the provider has this right, the anonymisation standard required, and the customer right to opt out.
The SaaS agreement must specify the post-termination data protocol: (1) a data export period (typically 30-90 days) during which the customer can extract all data in agreed formats, (2) the provider obligation to maintain data integrity during the export period, (3) read-only access to the platform during the export period (for verification), (4) the provider obligation to permanently delete all customer data from primary and backup systems after the export period, (5) a written certification of data destruction, and (6) the timeline for completing destruction (typically 30-60 days after the export period). Without these provisions, the customer data may remain on the provider servers indefinitely, creating ongoing DPDPA compliance obligations and data breach exposure.
SaaS pricing models include per-user (per seat per month), per-usage (API calls, storage, transactions), tiered (feature-based packaging), and flat-rate. The agreement should specify the pricing model, the unit of measurement, the billing frequency (monthly or annual), usage overage charges, and the process for adjusting user count mid-term (add immediately, remove at renewal). Auto-renewal is standard in SaaS agreements but must be balanced with customer flexibility: the cancellation notice period (typically 30-60 days before renewal), the renewal price escalation cap (typically 5-7% annually or CPI, whichever is lower), the customer right to downgrade at renewal, and clear disclosure of auto-renewal terms as required under consumer protection principles. Annual prepayment typically commands a 10-20% discount over monthly billing.
Enterprise SaaS providers should maintain SOC 2 Type II certification (audited controls for security, availability, processing integrity, confidentiality, and privacy), ISO 27001 certification (information security management system), and conduct annual penetration testing by independent firms. For healthcare SaaS, HIPAA compliance is relevant for US customers. For financial services, PCI-DSS compliance is required for payment data processing. The SaaS agreement should require the provider to maintain specified certifications throughout the subscription term, share audit reports and penetration test summaries on request, notify the customer of any certification failure or material audit finding, and comply with CERT-In reporting requirements under the IT Act 2000 for cybersecurity incidents.
SaaS platforms are continuously updated, features are added, modified, and deprecated. The SaaS agreement should specify the change management protocol: (1) advance notice for material changes (typically 90 days for feature deprecation, 30 days for enhancements), (2) the customer right to test changes in a sandbox environment before production deployment, (3) backward compatibility obligations for API changes (typically maintaining the previous API version for 12-24 months), (4) the customer right to terminate if a material feature relied upon at the time of subscription is deprecated, and (5) the provider obligation to provide migration tools and documentation for platform transitions. Without these provisions, the customer is subject to unilateral changes that may disrupt their business operations.
The SaaS agreement that works during the subscription is rarely the agreement that works during the exit. Data portability, transition assistance, and vendor lock-in mitigation must be designed at the procurement stage, not negotiated during the wind-down.