Copper Feed

Author: copperfeed

  • Seat Reclamation: Finding the Licences You Are Already Paying For

    Before you argue about the price of a licence, it’s worth checking how many you’re using. Most organisations are paying for a meaningful number of seats that nobody logs into, and that number is usually larger than any discount available at renewal.

    It’s also the only lever that doesn’t need the vendor to agree to anything. A discount is a negotiation. Reducing quantity is arithmetic.

    Where the dead seats come from

    Nobody buys licences they don’t need. They accumulate, and always through the same handful of routes.

    People leave, and offboarding removes their email and their VPN because those are the ones IT owns, while the six SaaS tools their manager expensed stay active. Teams reorganise, and the analytics seats bought for a project that ended are still renewing two years later. Someone runs a pilot with twenty seats, three people liked it, and the order form was for twenty. And the most expensive pattern of all: a whole department sits on a premium tier because two of them needed one premium feature, since it was easier to upgrade everybody than to manage two groups.

    None of that is negligence. It’s what happens when purchasing is fast and deprovisioning is nobody’s job.

    The count that changes a renewal

    You need three numbers per tool, and you can get them without buying anything.

    Seats purchased. From the order form, not from the admin console, because those disagree more often than you’d think and the contract is what you’re paying for.

    Seats assigned. From the vendor’s admin panel. The gap between purchased and assigned is pure waste and the easiest thing to fix, since you’re paying for seats that aren’t even allocated to a human.

    Seats actually used. Last login, or better, last meaningful action, over ninety days. Most admin panels expose this and the ones that don’t will usually hand it over if you ask your rep, which is a slightly awkward conversation and worth having.

    Then cross-reference the assigned list against your identity provider or HR system. Every account belonging to somebody who’s left is both a cost and a security problem, and framing it as the second one tends to get it prioritised faster than framing it as the first.

    The tier question, which is worth more than the seat count

    Once you have usage, ask a second question about the people who are active: are they using what they’re paying for?

    Tiered pricing assumes a team splits neatly into power users and everyone else. In practice most organisations put everyone on the higher tier for one of two reasons, either the feature they needed was gated there, or splitting the team into two groups sounded like ongoing admin work. That decision is often correct at the time and quietly wrong two years later, once the feature has moved down a tier or the people who needed it have moved on.

    Price the mixed configuration before renewal. Twenty premium and eighty standard is frequently a larger saving than any percentage you’d have won by arguing, and it’s a change you can make unilaterally.

    Doing it without buying a tool

    There’s an entire software category for this, and it’s genuinely useful past a certain size. Below that size it’s a spreadsheet and an afternoon.

    Start with your five most expensive subscriptions rather than all forty, because spend concentrates hard and the long tail can wait. Pull the assigned list from each admin panel, export your active employee list, and compare. Then look at last-login dates for whoever survives that pass.

    Your card statements and expense reports are the other half of the picture, since they surface the subscriptions that never went through procurement at all. That overlaps with finding the tools nobody approved, and it’s the same afternoon of work, so do both at once.

    Timing, which decides whether any of it counts

    Here’s the part that catches people. Finding twenty unused seats in month three of a twelve-month term saves you nothing, because you already bought them. Annual contracts almost never let you reduce mid-term, and the ones that do usually cap it.

    So the audit has to land before the renewal paperwork, ideally ninety days out, which is why it sits where it does in the renewal timeline. Do it early enough and the reduced count becomes your opening position. Do it late and it becomes next year’s problem.

    Watch for the co-termination trap too. Vendors like aligning all your products onto one renewal date, which is convenient, and it also means a single missed window commits you to everything at once.

    What to do with the number

    Reducing the count is the obvious move and sometimes the wrong one. If you’re going to grow into those seats within a few months, cutting them and buying them back at a worse rate is a bad trade, so check what re-adding costs before you cut.

    The alternative is to spend the number rather than bank it. A vendor facing a real reduction in seats will often protect the total contract value instead, which gives you room to ask for a rate hold, an uplift cap, better terms, or a tier upgrade for the people who need one. You’re converting waste into protection, and protection is what stops this from happening again.

    Either way you now know something you didn’t before, which is what you’re actually buying with an afternoon of spreadsheet work.

    CopperFeed tracks pricing and packaging changes as they’re announced, including the tier reshuffles that decide whether your current configuration still makes sense.

    General guidance, not legal or procurement advice. Your own contract terms govern what you can change and when.

  • Auto-Renewal and Uplift Clauses: The Four Contract Lines That Set Your Next Price

    Most of what happens at a renewal was decided when someone signed the original order form. The price you’re quoted, whether you can refuse it, and how much notice you get before your plan disappears are all set by contract language that took about four lines to write and that nobody read closely, because at signing everyone is thinking about whether the product works.

    Four clauses do nearly all of that work. They’re worth knowing by name, because they’re the ones you can still ask for, and because reading them in your current contract tells you in about ten minutes how much trouble your next renewal is going to be.

    1. The uplift cap, and the word it applies to

    An uplift cap limits how much the vendor can raise your rate at renewal. Three to five percent is common, and getting one at all is easier than most buyers expect, because a capped increase is still an increase and the vendor would rather have a predictable one than a fight.

    The trap isn’t the number. It’s the noun the cap attaches to.

    A cap on “renewal of the Plan” protects the plan you’re on. If that plan stops existing, and vendors retire plans constantly, the cap has nothing left to apply to and your quote comes back at list price for whatever replaced it. A cap on “renewal of the Services” follows you across that change, because the thing being capped is the relationship rather than one SKU.

    Same clause, same percentage, completely different outcome. If you read one line in your contract today, read that one.

    2. SKU continuity

    This is the clause that says: if you discontinue my tier mid-term, I move to the nearest equivalent at an equivalent effective rate, not at list.

    It matters because tier retirement is now the main way prices go up. Nobody sends a letter announcing a 24% increase. They announce that your plan is being consolidated into a new one, which happens to cost more and happens to be the only option, and technically your uplift cap was never breached because the plan it covered no longer exists. That’s the mechanics behind most of what shows up as a surprise renewal quote.

    Ask for continuity language and expect some resistance, because this is the clause that costs the vendor real money. It’s also the one worth spending your negotiating capital on, since it’s the only one that holds when the product line is reorganised around you.

    3. The notice period on tier retirement

    Separate from the price, there’s the question of warning. How long before your plan goes away do you find out?

    Market practice ranges from generous to insulting. Some vendors give a year. Others have given a handful of days on a full shutdown, which is not enough time to export data, let alone evaluate a replacement or get budget approved. Nothing stops that except a number in your contract, so put one there: ninety days minimum for a tier change, and more if switching would be a project rather than a swap.

    The same clause does double duty if the vendor goes away entirely rather than repricing, which is a different problem with a tighter clock.

    4. Auto-renewal and its notice window

    Nearly every subscription renews itself. The clause usually requires written notice of non-renewal 30, 60 or 90 days before the term ends, and if you miss that window you’re renewed, whether or not you ever signed a quote or wanted the product.

    Two things to negotiate here, neither of which is the existence of auto-renewal, because you won’t win that one.

    First, shorten the notice window. Thirty days is reasonable and ninety is not, and vendors concede this more readily than they concede money.

    Second, ask for a renewal notification obligation: the vendor must tell you in writing, at a set number of days out, that the renewal is coming and what the new price is. This costs them nothing and it removes the entire failure mode where a renewal lands because a calendar entry didn’t. It also means the price arrives while you still have time to do something about it, which is the whole argument of the renewal timeline.

    Reading your own contract

    You don’t need a lawyer for the first pass. Open the order form and the master agreement it references, and find four answers:

    • What’s the cap, and what word does it modify? Plan, or Services. If there’s no cap, that’s an answer too, and it means your next price is whatever they decide.
    • What happens if my tier is discontinued? If the contract is silent, assume list price.
    • How much notice do I get? Again, silence means whatever they feel like.
    • By what date must I give notice to not renew? Put that date in a shared calendar before you close the document. It’s the only one of the four you can’t fix later.

    Most contracts answer two of those four. The gaps are your list for the next negotiation, and the useful thing about asking for contract language rather than a discount is that it costs the vendor nothing today, which makes it much easier to say yes to.

    When to ask

    The best time is at initial signing, when you have the most leverage and the least information. The second best is at a renewal where you’re expanding, because adding seats or products is the moment your signature is worth something again. Asking for protection in a flat renewal, with no new money attached, is the weakest position, though it’s still worth doing since the answer is sometimes yes.

    What you’re buying with these four clauses isn’t a lower price. It’s the ability to know next year’s price this year, which turns out to be the thing that actually makes software budgets work.

    CopperFeed records repricings, tier retirements and shutdowns as dated entries, so you can see which vendors are reorganising their plans before the quote reaches you.

    General guidance, not legal or procurement advice. Contract language varies, and your own terms govern.

  • The SaaS Renewal Timeline: What to Do at 180, 90, 30 and 7 Days Out

    Most software renewals are decided long before anyone negotiates. The quote arrives three or four weeks out, someone forwards it to finance, finance asks whether the increase is normal, and by the time the answer comes back the auto-renewal clause has already done its work. The negotiation you think you are having is really just a request for a discount, made by the side with no time left.

    The fix isn’t a better script for that call. It’s starting earlier, because almost everything that gives you leverage takes weeks to assemble and nothing that matters can be done in the last fortnight.

    Here is what to do at each stage, working backward from the renewal date.

    180 days out: find the date and read the clause

    Two facts decide how much room you have, and most teams can’t answer either one on demand.

    The first is the actual renewal date, which is usually not the anniversary of when you started using the product. It’s the anniversary of the order form, and if you’ve added seats or co-termed a second product onto the same paper, it may have moved since. Go and find it in the document rather than in someone’s memory.

    The second is the notice window. Auto-renewal is standard, and the clause typically requires written notice of non-renewal 30, 60 or 90 days before the term ends. Miss that window and you’re contractually renewed at whatever the terms say, whether or not you ever sign a quote. That single date is the one to put in a shared calendar, because everything else is negotiable and this isn’t.

    While you’re in the contract, write down the four clauses that set next year’s price: the uplift cap if there is one, whether the cap applies to the plan or to the services as a whole, and what happens if the vendor discontinues your tier. Those clauses are what a forced SKU migration runs straight through, and knowing now whether you’re covered changes what you spend the next few months doing.

    90 days out: build the usage picture

    Vendors come to renewals holding your usage data. If you show up without your own version of it, every claim they make about adoption goes unchallenged, and you end up arguing about price when you should be arguing about quantity.

    Pull the seat list and compare it against your directory. Count the accounts that haven’t logged in this quarter, the ones belonging to people who’ve left, and the ones sitting on a premium tier for a feature they’ve never opened. In most organisations this is the largest single number available at renewal, and it’s bigger than any discount you were going to win. Counting it properly takes an afternoon.

    Then get the consumption picture, which matters more every year as pricing moves off seats. If any part of your bill runs on credits, tokens, API calls or workflow runs, chart the last twelve months and look at the slope, not the average. A commitment sized to your average usage looks cheap and overruns quarterly at rates you didn’t agree to. We went through how to size that in how to budget for usage-based pricing.

    This is also the point to check whether you’re paying twice for the same capability. Bundling has put transcription, search, document generation and assistant features into products that already sit in your stack, so the overlap tends to show up as two invoices doing one job.

    60 days out: decide what you’d actually do

    Leverage isn’t a tone of voice. It’s having a real answer to the question of what happens if you don’t sign, and that answer takes time to become real.

    Price one credible alternative properly. Not a threat, and you don’t have to mention it, but you should know the migration cost, the retraining cost and the number of weeks. If the honest answer is that you’re staying no matter what, that’s fine, and it’s better to know it going in, because then you stop pretending and start trading the things you can actually trade: term length, payment timing, a services credit, a cap on next year.

    Two other things belong in this window. Check whether your account is carrying an unresolved licensing question, because a true-up landing inside a renewal is the strongest card the vendor has, and it’s worth knowing what tends to trigger one. And confirm who signs on your side. A renewal that needs a signature nobody has scheduled is how teams end up accepting terms to avoid a lapse in service.

    30 days out: the conversation

    By now the quote exists. Ask for the line items, not the total, because the story is almost never a general increase. It’s a tier that no longer exists, a feature that moved up a level, a discount that was always time-limited, or a bundle you didn’t ask for. Each of those has a different counter, and you can’t pick one from a single number.

    Ask what the price is for the same thing you had. Sometimes there’s no such option, and that’s useful information, because it means you’re being migrated rather than renewed and the conversation should be about what protection carries over.

    Bring the seat count you built at 90 days. Reducing quantity is the one adjustment that doesn’t require the vendor to approve anything, and it changes the total more reliably than a percentage argument.

    7 days out: protect the floor

    Inside the last week you’re not negotiating price. You’re making sure nothing bad happens by default.

    If the notice window has passed and you don’t want the renewal, say so in writing anyway, then read what the contract actually obliges you to pay. If you’re signing, check the term length, the uplift language and the SKU-continuity wording one more time, because those three lines set next year’s starting position and they’re the ones that get edited quietly between drafts.

    And if the vendor is the one going away rather than repricing, the timeline changes shape entirely, which is its own playbook.

    The habit that makes this easy

    None of this is hard in isolation. It’s hard because renewals arrive scattered through the year and nobody owns the calendar, so each one feels like a surprise even when the contract has been sitting in a drive for eleven months.

    One shared list of renewal dates, notice windows and last year’s price fixes most of it. Add the date you’d have to start looking at alternatives, and the surprise goes away.

    CopperFeed tracks the other half: the launches, releases, repricings and shutdowns that show up in your quote months later. Pricing changes usually roll through a vendor’s customer base in a wave, so the first sign of yours is often a change that landed on somebody else.

    General guidance, not legal or procurement advice. Contract language varies, and your own terms govern.

  • Microsoft End of Support 2026: July Has Passed, October Has Not

    The Microsoft end of support date that mattered most this year was 14 July 2026, and it has passed.

    SharePoint Server 2016, SharePoint Server 2019, SQL Server 2016, and Project Server 2016 and 2019 all went out of support on that date. If you are still running any of them, you have been unsupported for roughly a month. That is the honest starting position, and most guidance on this topic is still written as though the deadline is ahead of you.

    What out of support actually means

    The software keeps working. Nothing switches off, no licence expires, and for a while nothing at all appears to happen. This is precisely why the risk gets deprioritised.

    What stops is security updates, bug fixes, technical support, and updated documentation. A vulnerability disclosed next month in SQL Server 2016 does not get a patch. The exposure does not arrive on the deadline. It accumulates afterwards, quietly, and the first evidence is usually either an audit finding or an incident.

    Extended Security Updates exist for some products and are worth pricing. Understand what you are buying: critical security fixes, not support and not features. ESU is a way to schedule your migration on your own terms rather than an alternative to doing it.

    Where this bites first

    Not from attackers. From paperwork.

    Unsupported software fails questionnaires. Your cyber insurance renewal asks whether you run supported versions. Customer security reviews ask. SOC 2 and ISO auditors ask, and an unsupported database holding customer data is a finding rather than a discussion. Any one of those can surface months before an attacker does, and each of them arrives with a deadline attached.

    If you are past 14 July on any of the above, the useful move this week is a written statement of position: what is still running, what compensating controls exist, and what the migration plan and date are. You will need that document for at least one of the conversations above, and writing it now is considerably easier than writing it under a customer’s timeline.

    The dates still ahead

    Two are close enough to plan for.

    13 October 2026. Office 2021 retires, covering Word, Excel, PowerPoint, Outlook, Access, OneNote, Publisher, Project and Visio. Windows 11 Home and Pro version 24H2 shares the same date. This one reaches end users rather than servers, which makes it a rollout problem rather than a migration project, and rollouts are slower than people plan for.

    10 November 2026. Windows 11 Enterprise, Education and IoT Enterprise 23H2.

    Windows 10 2016 LTSB and Windows Server 2012 and 2012 R2 also reach their dates during October. Microsoft’s lifecycle page lists more than fifty products, versions and Azure services losing support across 2026, so the five names above are a starting point rather than an inventory.

    Do the inventory against the lifecycle page

    The most common failure here is not ignoring a known deadline. It is not knowing something is running.

    Old SQL Server instances survive under applications nobody associates with a database. SharePoint farms outlive the project that needed them. A version you decommissioned frequently has one node left that somebody kept for a report.

    Take your actual estate, check it against Microsoft’s published lifecycle data rather than against memory, and record a date next to every version. That list is what makes the next three years predictable instead of a series of surprises.

    Why we cover this

    End of support is the most orderly version of a shutdown. It is announced years ahead, published on a page anyone can read, and it still catches organisations out, which tells you something useful about the disorderly versions.

    The difference between this and a SaaS vendor deciding to retire a product is that here you keep running the software after the date. The exposure is slower and easier to ignore. That does not make it smaller.

    The general playbook is in Your Vendor Is Shutting Down. A live example with a shorter fuse is Opsgenie’s April 2027 end of life. CopperFeed records retirements as they are announced.

    Dates here reflect published reporting on Microsoft’s lifecycle announcements at the time of writing. Verify against Microsoft’s own lifecycle documentation before planning against them, and check ESU eligibility per product.

  • Opsgenie End of Life: The April 2027 Deadline

    Opsgenie end of life is 5 April 2027. Atlassian announced it in March 2025 and closed the product to new customers on 4 June 2025, so anyone still running it has been on a product with a published expiry date for well over a year.

    That is unusually generous notice for a shutdown. It is also why so many teams have not started, and why the deadline will still surprise people.

    The dates

    March 2025 Announced
    4 June 2025 End of sale. No new customers or trials. Existing customers can still add seats.
    5 April 2027 End of life. Data not migrated by this date is permanently deleted.

    Note the shape of that last one. This is not a case where access ends and the data sits in cold storage while you sort yourself out. The published position is deletion at shutdown.

    Where Atlassian wants you to go

    Into Jira Service Management, with alerting folded into the Premium and Enterprise tiers, and Compass for service cataloguing. Opsgenie is not being replaced by one thing so much as absorbed into two.

    Two consequences worth pricing before you assume the in-house path is the easy one.

    The alerting capability lands in higher JSM tiers, so the migration may carry a tier upgrade with it. If you are on a lower tier today, the cost of staying with Atlassian is not zero, and it is worth getting that number early rather than at renewal, when it becomes a different conversation. That is a familiar pattern, and we wrote about the general version in legacy plan sunsets.

    The second is a scope question. Opsgenie was a focused on-call and alerting product. If the replacement is a service management platform plus a service catalogue, you are adopting more surface area than you retired, and adoption of surface area you did not ask for is where migration timelines go wrong.

    How long it actually takes

    Longer than a feature comparison suggests, and this is the number to plan around.

    Teams that have done it report six to sixteen weeks depending on integration count. Straightforward setups still land at six to eight. On-call tooling is unusually entangled: escalation policies, rotation schedules, overrides, holiday handling, and an integration for every monitoring system you run. Each of those is small and none of them are optional.

    The approach that consistently works is a parallel run. Configure the new platform, page both systems for two to four weeks, verify that the new one fires correctly for real incidents, then cut over. Nobody wants to double-page their on-call engineers. Everybody who skipped it has a story about the alert that did not arrive.

    Rotations and escalation policies are also the part that does not export cleanly. Expect to rebuild rather than import, and budget for someone who understands why the current policies are shaped the way they are, because half of that logic exists because of an incident nobody wrote down.

    Reading the alternatives

    Search this and you will find a large number of migration guides published by incident management vendors. Several are genuinely good, particularly on export mechanics and on the parts of the migration that bite, because these companies have run the process many times.

    They also all conclude that you should move to them. Use them for the mechanics and build your own shortlist. CopperFeed does not rank tools, so this page will not hand you one either.

    If you have not started

    You have roughly twenty months at the time of writing, which sounds comfortable and is not once you subtract a procurement cycle, a parallel run, and the fact that nobody will prioritise this until it is urgent.

    1. Export the configuration now. Schedules, escalation policies, integration list, team structure. Not because you are migrating today, but because that export is the requirements document for whatever you choose.
    2. Price the JSM path properly. Including any tier change. It is the baseline every alternative gets compared against, and you cannot compare without it.
    3. Count your integrations. This single number predicts your timeline better than anything else.
    4. Book the parallel run in the calendar. Working backward from April 2027, not forward from whenever the project starts.

    The general version of this is in Your Vendor Is Shutting Down. CopperFeed records retirements as they are announced.

    Dates and migration timings here come from Atlassian’s published announcements and from practitioner and vendor accounts, attributed where linked. Verify current dates against Atlassian directly before planning against them.

  • Your Vendor Is Shutting Down: A Playbook for the First Two Weeks

    Notice periods for a SaaS shutdown range from about two years to about four days.

    Atlassian told Opsgenie customers in March 2025 about an April 2027 end of life. Productiv announced the retirement of its platform on 6 August 2026 and shut it down four days later. Same category of event, two orders of magnitude apart in warning.

    You do not get to choose which kind you get. What follows assumes the bad one, and scales down cleanly if you were lucky.

    Week one: get the data out

    Before evaluating replacements, before the vendor call, before telling anyone. Export first, because it is the only step with a hard deadline you do not control.

    Two dates matter and they are not the same date. Access ends when the product stops working. Deletion happens later, sometimes much later, sometimes days later, and the second one is the one that ends your options. Find both in writing.

    Then check what you actually got, because a completed export is not a complete export. The gaps are consistent across products:

    • Attachments and documents. A row-per-record CSV rarely brings the files with it, and files are the part you cannot reconstruct.
    • History. Current state exports give you today. What something cost, or who owned it, three years ago frequently does not survive.
    • Archived and deleted records. Exports tend to default to active. Your retention obligations do not.
    • Anything computed. Balances, scores and rollups are calculations. Without the inputs and the rules, the number is a screenshot.

    Open the files. Do not assume a download that finished is a download that worked.

    Week one, in parallel: work out what actually depends on it

    Usually more than the team that owns it thinks, and the dependencies are rarely documented.

    Look for scheduled reports going to people outside the team, integrations pushing data into other systems, single sign-on relationships, anything with a webhook, and any process where this tool is the system of record rather than a convenience. That last category is what turns a tool migration into a compliance problem.

    Week two: replacements, with your eyes open

    Now you can evaluate, and you will be reading a lot of content written by people who want to sell you the answer.

    Search any shutdown and the results are dominated by competitors publishing migration guides. Some are genuinely excellent on export mechanics, because they have done the migration dozens of times and know where the data hides. All of them arrive at a shortlist they are on.

    Read them for the mechanics. Build your own shortlist. The two activities are separate and the pages are designed to blur them.

    Give real weight to how long migration takes rather than to feature comparison. Teams moving off Opsgenie with straightforward setups still report six to eight weeks, and more with heavy integrations. Feature parity is a spreadsheet exercise. Elapsed time is what determines whether you make the deadline.

    The recovery nobody thinks of

    If the data is already gone, or the export came back thin, stop looking at the dead vendor and look downstream.

    Most of what you lost exists somewhere else, because systems that integrated with the dead one kept copies. Your data warehouse, your accounting system, the SFTP destination somebody set up years ago, the reporting tool that pulled a nightly extract, the other SaaS product that syncs contacts. Reconstruction from downstream systems is usually more complete than people expect, and nobody tries it because the instinct is to grieve the primary source.

    Then fix the thing that let it hurt

    Once the fire is out, two contract terms are worth adding everywhere. A minimum notice period on discontinuation, and a defined post-termination data retention window with an export format specified. “You can export your data” and “you can export your data in a form another system can read” are different promises.

    Worth checking whether your existing agreements have either. Most do not, which is how a four-day notice becomes legal.

    The worked example is what happened to Lattice HRIS customers, where the product died on schedule and the data deletion terms turned out to be worse than the standard policy everyone assumed applied. CopperFeed records shutdowns and retirements as they are announced, which is the only version of this that gives you time.

    General guidance, not legal advice. Retention obligations and contract terms vary, and your own agreement governs.

  • Subprocessors: The Vendors Behind Your Vendor

    A subprocessor is a company your vendor uses to deliver its service, which means it is a company handling your data because of a decision you did not make.

    You approved one vendor. That vendor approved five more. Those five have their own. The list is longer than it used to be, and at AI vendors it is growing faster than anywhere else in software.

    Why the chain got longer

    Legacy SaaS could plausibly run on its own infrastructure with a cloud provider underneath. An AI feature typically cannot.

    A single assistant inside a product you already license routinely involves the model provider, the cloud that model runs on, a content moderation service, an analytics provider and security tooling. Five parties for one feature, most of them invisible from your side, none of them chosen by you.

    None of that is improper. It is how the stack is assembled, and a vendor building all five in-house would be worse at four of them. The problem is not the existence of the chain. It is that your diligence stops at the first link while your data does not.

    The notice window is the real issue

    Well-drafted DPAs commit the vendor to publishing its subprocessor list, giving notice before adding to it, and providing a mechanism for you to object.

    The mechanism has been hollowed out by the calendar. At most AI vendors the realistic notice window has compressed to somewhere between 14 and 30 days.

    Consider what that asks of you. You receive notification that a new company will process your data. You have two to four weeks to assess an organisation you have never evaluated, form a view, and object, with objection typically meaning you may terminate. In practice nobody does this, and everybody knows nobody does this. The clause is satisfied and the diligence is theatre.

    Negotiate the window if you have leverage. Thirty days is a floor worth holding, sixty is worth asking for, and a vendor that will not commit to publishing the list at all has told you something useful.

    What to actually do about it

    The realistic goal is not evaluating every subprocessor. You will not, and pretending otherwise produces a process that gets abandoned. The goal is knowing which links matter and noticing when they change.

    1. Get the list, dated. Save a copy rather than bookmarking the page. Vendors update these quietly and you want to be able to diff.
    2. Subscribe to the notification list. Most vendors offer one and it is not on by default. Route it to a shared inbox rather than one person, because the one person changes jobs.
    3. Care about two categories. Anyone processing content rather than metadata, and anyone in a jurisdiction that changes your transfer position. The analytics provider counting page views is not your risk. The model provider reading everything your staff type is.
    4. Check the model provider specifically. Frequently the most consequential name on the list, and frequently the one buyers assume is the vendor itself. A product with its own branded assistant may be routing to somebody else’s model entirely.
    5. Re-read after any acquisition. Your vendor being acquired can change its subprocessor chain wholesale, and the notice you get will be about the acquisition rather than about the data.

    The version nobody catches

    Everything above assumes a change you are told about. The harder case is the one that arrives as a product announcement.

    A vendor ships an AI feature into a tool you have used for years. To deliver it they add a model provider. Your contract has not changed, your vendor list has not changed, and the number of companies processing your data has gone up. If the subprocessor page was updated, it was updated quietly, and the release notes described a feature rather than a data flow.

    This is the same failure that runs through everything on this blog. Your records stayed accurate and the product moved. Watching vendor releases and changelogs for the ones that change data handling is what CopperFeed exists to record.

    The broader checklist is in AI Vendor Due Diligence, and the training question in Does Your AI Vendor Train on Your Data.

    Notice windows and subprocessor practices described here reflect published guidance at the time of writing and vary by vendor and contract. General guidance, not legal advice. Your own DPA governs.

  • Does Your AI Vendor Train on Your Data?

    “Does this vendor train on my data” sounds like a yes or no question. It is not. The honest answer for most major AI vendors is “it depends which account you are using”, and that is the finding that matters.

    The tier is the answer

    At the large providers, commercial and enterprise tiers contractually prohibit training on customer data. Consumer tiers frequently permit it, by default, at the same company under the same brand.

    So the question your security review answered is not the question your organisation is exposed to. Your review covered the enterprise agreement. Your exposure includes every employee who signed up for a free account with a work email address, and that account runs under consumer terms.

    Same interface. Same model. Opposite default. Nothing on screen tells the user which side of the line they are on.

    This is why shadow AI and data governance are the same problem rather than two adjacent ones. An unsanctioned free account is not merely untracked software. It is software operating under the permissive version of the terms you negotiated away.

    Defaults move

    The second thing people get wrong is treating this as a fact to establish once.

    Both OpenAI and Anthropic have changed consumer training defaults within roughly the last eighteen months. Not obscure policy footnotes. The default behaviour of the products your staff use most.

    A verification from last year is a historical record. If your process is an annual questionnaire, your answer is out of date for most of the year, and nothing in the questionnaire process will tell you when it changed.

    What to actually check

    Ignore the marketing page. It will say something reassuring that is true of one tier.

    1. Find the terms that govern each tier separately. Consumer terms, business terms, enterprise agreement, API terms. Four documents, frequently four different answers.
    2. Look for the opt-out and who holds it. On consumer tiers, training is often on by default with a per-user setting buried in preferences. A control that lives with the individual user is not a control you have.
    3. Separate training from human review. Distinct commitments. A vendor can truthfully say it does not train on your data while staff review conversations for abuse or quality, which is a different disclosure with different implications.
    4. Check retention alongside it. “We do not train on it” and “we do not keep it” are unrelated statements. API retention typically runs 7 to 30 days, and zero data retention usually requires approval rather than a toggle.
    5. Ask what governs a work email on a free account. The question that produces the useful answer, and the one nobody asks.

    The practical fix

    You will not solve this with policy language alone, because the people creating the exposure are not reading the policy.

    What works is removing the reason to use the consumer tier. Provision enterprise accounts for anyone who wants one, make getting one faster than signing up personally, and say plainly which account to use for work. Most people are not attached to their free account. They are attached to not waiting three weeks.

    Where you can, use domain capture or SSO enforcement so that work email addresses cannot create standalone consumer accounts in the first place. That converts a policy problem into a configuration problem, which is a much better class of problem.

    Then keep watching

    Whatever you verify today has a shelf life. Consumer defaults change, enterprise terms get revised, and new features ship with their own data handling that the original agreement never contemplated.

    Tracking those changes is what CopperFeed is for. The full diligence checklist is in AI Vendor Due Diligence, and the chain of companies behind your vendor is in Subprocessors.

    Vendor defaults described here reflect published comparisons at the time of writing and change without notice. Verify against current terms for the specific tier you use. General guidance, not legal advice.

  • AI Vendor Due Diligence: What to Check Before You Sign

    AI vendor due diligence is the same exercise you already run on any processor, plus four questions that did not exist five years ago and that most security questionnaires still do not ask.

    The general parts are well covered elsewhere. This is the delta.

    The four AI-specific questions

    Any AI vendor processing personal data on your behalf is a processor under GDPR Article 28, so a valid DPA is a legal requirement rather than a nice-to-have. Assume that part is table stakes and go looking for these.

    1. Training defaults, per tier

    The one that catches people. Commercial tiers at the major vendors contractually prohibit training on customer data. Consumer tiers frequently permit it, at the same brand, under the same logo.

    Your diligence covers the enterprise agreement you signed. It says nothing about the free account an employee opened with a work email, which runs under consumer terms and a different default. Two people at your company can paste the same document into what looks like the same product and get opposite outcomes.

    These defaults also move. OpenAI and Anthropic have both changed consumer defaults within roughly the last eighteen months. A policy you verified last year is not a policy you have verified.

    2. Retention

    Ask how long inputs and outputs are held, and separate the API answer from the product answer, because they are usually different.

    API retention commonly runs somewhere between 7 and 30 days. Anthropic has been at 7 days, described in vendor comparisons as the strongest default in the market; OpenAI has been at 30. Zero data retention exists at several vendors but generally requires approval rather than a checkbox, which means it needs to be asked for during procurement rather than discovered afterwards.

    3. Subprocessor depth

    AI vendors stack subprocessors faster than legacy SaaS did, and the chain is longer than most buyers expect. A single AI feature routinely involves the model provider, the cloud it runs on, a content moderation service, an analytics provider and security tooling.

    Each is a place your data goes. This deserves its own treatment, in Subprocessors: The Vendors Behind Your Vendor.

    4. Transfer mechanism, read properly

    Standard Contractual Clauses in the 2021 form, the UK Addendum where relevant, and a transfer impact assessment. None of that is new.

    What is worth your attention is the carve-outs. Vendors advertise EU-only processing and then except support access, abuse monitoring, or a subprocessor that is not regional. An EU-only claim needs reading line by line, because the exceptions are where the transfers actually happen.

    Why the paperwork alone is not enough

    A DPA describes an intended arrangement at a moment in time. It does not tell you what is running today.

    Three things change after signature and none of them require your consent. Subprocessors get added, and the notice window at most AI vendors has compressed to somewhere between 14 and 30 days, which is not long enough for a real assessment. Defaults get revised, as the consumer flips demonstrate. And the vendor ships a new AI feature into a product you already licensed, which changes what the software does with your data without changing a word of your contract.

    That last one is the gap between due diligence as practised and due diligence as needed. Your review was accurate. The product moved.

    A workable process

    1. Ask the tier question explicitly. Not “do you train on customer data” but “which of your tiers permit training, and what governs an employee using a free account with a work email”. The second question gets a much more interesting answer.
    2. Get zero data retention decided during procurement. It is an approval, not a setting, and asking later means asking without leverage.
    3. Require the published subprocessor list and an objection mechanism, and negotiate the notice window upward if you can. Fourteen days is not a diligence period.
    4. Diff the DPA annually. Vendors update these pages quietly. Keep a dated copy of what you agreed to so you can see what moved.
    5. Watch the product, not just the contract. Vendor changelogs are where new data processing shows up first.

    That last step is the one nobody staffs, and it is what CopperFeed records: dated entries for the releases and repricings that change what your software does.

    The training question in detail is in Does Your AI Vendor Train on Your Data. And none of this reaches tools nobody told you about, which is shadow AI.

    Vendor-specific retention and training defaults cited here reflect published comparisons at the time of writing and change without notice. General guidance, not legal advice. Verify current terms and take advice on your own obligations.

  • The End of Per-Seat Pricing: What AI Agents Do to Your Licence Count

    Per-seat pricing worked because seats and value moved together. More people using the software meant more work getting done, so charging per person was a rough but honest proxy.

    AI agents break the proxy. An agent does the work and never logs in.

    The arithmetic that panicked the industry

    Take a support team of fifty on a CRM at $150 a seat. Deploy agents that handle most of the ticket volume, keep fifteen people for escalations, and the work still gets done. The vendor’s revenue from that account falls by seventy percent while the customer’s outcome is unchanged or better.

    Nobody churned. Nobody complained about price. The unit the contract was denominated in simply stopped correlating with the value delivered.

    That is the whole story, and it explains behaviour across the industry in 2026 that otherwise looks like ordinary greed.

    What vendors are doing instead

    Four responses, and most large vendors are running more than one.

    Metering the agent. The seat survives, wrapped in a consumption meter for delegated work. Salesforce, Microsoft, ServiceNow, Workday, Zendesk, HubSpot and Atlassian have all added a version of this. Reporting puts Salesforce’s agent revenue at around $800 million in a single recent quarter, and Microsoft has added a separate per-user charge for agent governance in the region of $15.

    Licensing the agent as a user. Agents get identities, authenticate, and appear in the billing system much as employees do. Conceptually tidy, and it makes the seat count go back up.

    Outcome pricing. Charging per resolved ticket, reviewed contract or qualified lead. Goldman Sachs has taken to calling this Results-as-a-Service. Attractive in a demo, hard to write, since it requires both sides to agree what counts as a result and who adjudicates when they disagree.

    The flat agentic bundle. Salesforce’s Agentic Enterprise License Agreement replaces per-seat and consumption billing with a flat unlimited-use fee across a multi-year term. Predictability in exchange for commitment and lock-in, which is a genuine trade rather than a trick.

    How fast this is moving

    Seat-based arrangements are reported to have fallen from roughly 21% to 15% of enterprise software contracts in about a year. IDC expects 70% of vendors off pure per-seat models by 2028. Hybrid structures, a base fee plus a variable component, are said to be running around 43% of SaaS companies and heading toward 61%.

    Numbers like these come from analyst and vendor research with an interest in the narrative, so hold them loosely. The trend is corroborated by the thing that is hardest to spin, which is what vendors actually shipped: nearly every major platform changed how it charges within the same eighteen months.

    What it means if you are buying

    The comfortable assumption to abandon is that headcount reductions produce software savings. Under the new models they may not, and under a flat agentic bundle they explicitly do not.

    Practical consequences:

    • Your renewal maths changes. Cutting seats used to be the reliable lever. If the value has moved into a meter, cutting seats saves less than you expect and may trigger an audit. See what triggers a software audit.
    • Two vendors are no longer comparable. One prices per seat, one per outcome, one per credit. Comparing them requires modelling your own workload, not reading a pricing page.
    • Agents multiply, employees do not. Headcount is bounded by hiring. Agent count is bounded by whoever can deploy one, which is a much looser constraint and a much faster-moving cost.
    • Term length is the real negotiation. Flat bundles buy predictability with lock-in, at exactly the moment the market is repricing. Two years is a long time to be certain about this.

    The one thing to do now

    Find out, for your largest contracts, whether the metric has already changed. Not the price. The metric.

    A per-seat agreement that quietly became per-seat-plus-consumption is a different contract from the one you signed, and it usually arrives as a product announcement rather than as a commercial notice. Most organisations discover it on an invoice.

    Tracking those changes is what CopperFeed is built for. The credit mechanics are in AI Credits Explained, and forecasting against them in How to Budget for Usage-Based Pricing.

    Figures here come from published analyst and press reporting rather than vendor disclosure, and are indicative. General guidance, not procurement advice.