Category: Shutdowns & Migrations

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 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.

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.

Lattice HRIS is gone. Not going, gone. Payroll access ended on 31 March 2026, HRIS access ended on 31 July, and reporting indicates customer data was permanently deleted on 6 August.

Almost every guide you will find on this shutdown was written for people who still had time. If you are reading this in August 2026 or later, you do not, and the advice you need is different. This page covers what is actually still available.

The timeline

November 2025	Lattice announces it is discontinuing HRIS and payroll
31 March 2026	Payroll access ends
April 2026	A Rippling-formatted census export is added
31 July 2026	HRIS access ends permanently
6 August 2026	HRIS customer data reportedly deleted

Roughly eight months of notice, which is more than plenty of vendors give. The sting is at the end of the list rather than the beginning.

One sourcing note, because it matters here. The 6 August deletion date and the detail that Lattice’s standard 180-day retention window does not apply to HRIS customers come from a single published guide. We have not seen that confirmed in a Lattice notice we can link to. If your data matters, treat it as a strong signal to go and check rather than as settled fact, and ask Lattice directly.

What did not shut down

Worth being precise, because the headline confuses people. Lattice the company is fine. Lattice discontinued its HRIS and payroll products and is refocusing on performance management, and the Talent Suite (reviews, goals, OKRs, 1:1s, engagement surveys, compensation planning) carries on. Existing customers have been offered discounts on it.

So if you use Lattice for performance reviews, nothing happened to you. If you used it as your system of record for people and pay, everything did.

If you exported before 31 July

Check what you actually got, because CSV exports are where this goes wrong quietly. The admin panel covered People, Time Off, Time Tracking, Goals, Updates, Engagement and Custom Reports. What tends to be thin or missing:

• Uploaded documents. Signed offer letters, policy acknowledgements, visa and I-9 paperwork. These rarely come out in a row-per-employee CSV, and they are the ones you cannot recreate.
• Historical effective dates. A current-state export gives you today’s salary and title. It does not always give you the compensation history behind them, which is what you need for pay equity analysis and for anyone asking about promotions three years ago.
• Terminated employees. Exports frequently default to active staff. Your retention obligations do not.
• Time-off balances mid-accrual. A balance is a calculation, not a fact. Check that the accrual rules came with the number.

Open the files. Do not assume a download that completed is a download that is complete.

If you did not export

Do these in order, today.

1. Contact Lattice support in writing and ask directly. Ask whether any copy of your data still exists, in any system, including backups, and ask them to answer in writing. A deletion date published in a third-party guide is not the same as a confirmed irreversible deletion of your tenant. This is a five-minute email and it is the only step that could recover everything.
2. Reconstruct from the systems that were downstream of Lattice. This is where most of your data actually still lives. Your payroll provider holds pay history. Benefits carriers and your 401(k) administrator hold enrolment, dependants and deduction records. Your ATS holds hire dates and offer details. If anything was piped out over SFTP, the destination still has it. If you ran that Rippling census export in April, that file is a census.
3. Check your own accounting system. Payroll journal entries in the general ledger will reconstruct compensation history further back than most people expect.
4. Then worry about the new HRIS. Counterintuitive, but recovery is time-sensitive and vendor selection is not.

The part nobody puts in the migration guides

Losing payroll records is not only an operational problem. Employers in the US have statutory retention obligations: broadly, three years for payroll records under the FLSA and four years for employment tax records under IRS rules, with state requirements layered on top and longer clocks for some categories. Those obligations sit with you, not with the vendor who deleted the database.

If you have gaps, that is a conversation to have with your employment counsel now rather than at your next audit. We are a change feed, not a law firm, and this is the point where you want a real one.

Where people went instead

CopperFeed does not rank tools, so this is a list rather than a recommendation. Vendors and coverage around this shutdown have most often pointed at HiBob, Rippling, BambooHR, Factorial, Calamari, HR Partner and MHR.

Read all of it with the obvious caveat in mind: nearly every “Lattice is shutting down” guide currently ranking was published by a company selling a replacement. That does not make them wrong, and several are genuinely useful on export mechanics. It does mean the shortlist you are reading was assembled by someone on it.

The lesson worth taking

Lattice gave eight months of notice, which is not the failure here. The failure is that the data retention terms turned out to be worse than the standard policy customers assumed applied, and nobody discovers that until the shutdown notice lands.

Two things to check in every vendor contract you hold, while this is fresh:

• What is the post-termination data retention window, and does it apply to every product line? Lattice’s 180 days reportedly did not extend to HRIS customers. A retention promise in a master agreement can be undercut by a product-specific schedule.
• What export format are you entitled to, in writing? “You can export your data” and “you can export your data in a form another system can ingest” are very different commitments, and only one of them helps at 3am in week ten of a migration.

More on contract terms that survive this kind of event in Grandfathered SaaS Pricing Is Ending. The running list of retirements is in Legacy Plan Sunsets: Every SaaS Tier Being Retired in 2026.

Dates and export details here come from published third-party reporting, linked inline, and had not been confirmed against a Lattice notice at the time of writing. If you know differently, tell us and we will correct it and say what changed.