{ "$schema": "https://lastcall.dev/api/sunsets.json", "generated": "2026-09-18T08:00:18.391Z", "license": "CC-BY-4.0", "attribution": "Last Call — https://lastcall.dev", "count": 82, "sunsets": [ { "id": "google-reader-shutdown", "url": "https://lastcall.dev/entries/google-reader-shutdown", "title": "Google Reader shutdown", "vendor": "Google", "what": "Google Reader was shut down", "category": "SaaS", "sunsetDate": "2013-07-01", "status": "passed", "impact": "Google retired its RSS reader on 1 July 2013, giving users about three and a half months to export their subscriptions via Google Takeout and move to another reader. It became the defining example of a beloved free product being switched off.", "migration": "Export your subscriptions as OPML from Google Takeout and import into another feed reader.", "alternatives": [ "Feedly", "The Old Reader", "NewsBlur", "Self-hosted (e.g. FreshRSS, Miniflux)" ], "detect": [], "source": { "url": "https://googleblog.blogspot.com/2013/03/a-second-spring-of-cleaning.html", "label": "A second spring of cleaning — Official Google Blog" }, "updated": "2026-07-19" }, { "id": "python-2-eol", "url": "https://lastcall.dev/entries/python-2-eol", "title": "Python 2 end-of-life", "vendor": "Python", "what": "Python 2.7 reached end-of-life", "category": "Runtime", "sunsetDate": "2020-01-01", "status": "passed", "impact": "No more bug fixes, security patches, or improvements to Python 2 from the core team. Anything still on 2.7 runs unmaintained; new CVEs will not be fixed upstream.", "migration": "Move to Python 3. The 2to3 tool and the compatibility notes in the porting guide cover most mechanical changes; the harder work is usually str/bytes handling and dependencies that dropped 2.x support.", "alternatives": [ "Python 3.x (the supported line)" ], "detect": [ "image:python:2", "runtime:python:2" ], "source": { "url": "https://www.python.org/doc/sunset-python-2/", "label": "Sunsetting Python 2 — python.org" }, "updated": "2026-07-19" }, { "id": "adobe-flash-eol", "url": "https://lastcall.dev/entries/adobe-flash-eol", "title": "Adobe Flash Player end-of-life", "vendor": "Adobe", "what": "Adobe Flash Player reached end-of-life", "category": "Feature", "sunsetDate": "2020-12-31", "status": "passed", "impact": "After 31 December 2020 Adobe stopped updating and distributing Flash Player, and blocked Flash content from running in the player from 12 January 2021. Browsers removed Flash support entirely. Any product depending on Flash stopped working.", "migration": "Rebuild interactive content on open web standards — HTML5 Canvas, WebGL, and CSS animation. Adobe Animate can export existing Flash projects to HTML5.", "alternatives": [ "HTML5 Canvas / WebGL", "Adobe Animate (HTML5 export)" ], "detect": [], "source": { "url": "https://www.adobe.com/products/flashplayer/end-of-life.html", "label": "Adobe Flash Player EOL — adobe.com" }, "updated": "2026-07-19" }, { "id": "centos-7-eol", "url": "https://lastcall.dev/entries/centos-7-eol", "title": "CentOS 7 end-of-life", "vendor": "CentOS / Red Hat", "what": "CentOS Linux 7 reached end-of-life", "category": "OS", "sunsetDate": "2024-06-30", "status": "passed", "impact": "After 30 June 2024, CentOS Linux 7 receives no further updates or security patches. It was the last CentOS Linux release; the traditional \"free RHEL rebuild\" model ended with it in favour of CentOS Stream.", "migration": "Move to a RHEL-compatible rebuild (AlmaLinux, Rocky Linux), to CentOS Stream, or to RHEL itself. Conversion tooling exists for in-place migrations.", "alternatives": [ "AlmaLinux", "Rocky Linux", "CentOS Stream", "Red Hat Enterprise Linux" ], "detect": [ "image:centos:7" ], "source": { "url": "https://www.redhat.com/en/topics/linux/centos-linux-eol", "label": "CentOS Linux EOL — Red Hat" }, "updated": "2026-07-19" }, { "id": "nodejs-20-iron-end-of-life", "url": "https://lastcall.dev/entries/nodejs-20-iron-end-of-life", "title": "Node.js 20 (Iron LTS) reached end of life on April 30, 2026", "vendor": "Node.js", "what": "Node.js 20 \"Iron\", the LTS line, reached end of life on April 30, 2026. The 20.x branch now receives no further releases of any kind, including security fixes, so applications and container images pinned to `node:20` no longer get patched.", "category": "Runtime", "sunsetDate": "2026-04-30", "status": "passed", "impact": "Every Node.js release line gets about 30 months of support: roughly six months as \"Current\", then Active LTS, then a Maintenance window, after which it hits end of life and is dropped entirely. Per the official Node.js release schedule, the 20.x \"Iron\" line entered Maintenance on October 22, 2024 and reached **end of life on April 30, 2026**. After that date the Node.js project ships no more 20.x releases — not even for critical security vulnerabilities — so anything still on Node.js 20 keeps running but accumulates unpatched CVEs in the runtime, its bundled V8 engine, and npm. Node.js 20 is one of the most widely deployed lines: it backs a large share of production services and the official `node:20` Docker images, including the common `node:20-alpine`, `node:20-bookworm`, and `node:20-slim` tags used across application builds and CI. It does not affect Node.js 22 \"Jod\" (LTS, end of life April 30, 2027) or Node.js 24 \"Krypton\" (current, end of life April 30, 2028), which remain supported on their own schedules.", "migration": "Move to a supported Node.js LTS line — 22 \"Jod\" or 24 \"Krypton\" — as soon as possible; every day on Node.js 20 past its end-of-life date is a day on an internet-facing runtime that will never be patched again. Most application code runs on 22 and 24 unchanged, but review the changelogs for removed APIs and behavior changes, bump your `engines` field and any `.nvmrc` / CI matrix, and run your test suite against the target runtime. For Dockerized apps, change the base image from `node:20` (and `node:20-alpine` / `node:20-slim` / `node:20-bookworm`) to the matching `node:22` or `node:24` tag and rebuild. Check that native addons and any dependencies with prebuilt binaries publish builds for the target Node.js version before you cut over.", "alternatives": [ "Node.js 22 \"Jod\" — Active LTS; end of life April 30, 2027", "Node.js 24 \"Krypton\" — the current release, entering LTS; end of life April 30, 2028", "A commercial extended-support offering (e.g. HeroDevs Never-Ending Support) only as a stopgap if an upgrade genuinely cannot be completed in time" ], "detect": [ "image:node:20" ], "source": { "url": "https://github.com/nodejs/Release", "label": "Node.js Release schedule — nodejs/Release (official release working group)" }, "updated": "2026-09-14" }, { "id": "tenor-api-shutdown", "url": "https://lastcall.dev/entries/tenor-api-shutdown", "title": "Google shut down the Tenor GIF API on 30 June 2026, breaking GIF pickers in Discord, X, WhatsApp and Bluesky", "vendor": "Google (Tenor)", "what": "Google decommissioned the Tenor API — the GIF search and share service behind GIF pickers across the web — on 30 June 2026, terminating all API and Ads Distribution Agreements and ending third-party access with no official replacement", "category": "API", "sunsetDate": "2026-06-30", "status": "passed", "impact": "The Tenor API was the GIF search-and-share backend embedded in a huge range of apps — the GIF picker in Discord, X/Twitter, WhatsApp, Bluesky, Slack integrations, countless chat clients and bots. Google's [official support notice](https://support.google.com/tenor/answer/10455265) sets two dates: on **13 January 2026** Tenor stopped accepting new API key sign-ups and new integrations, and on **30 June 2026** it terminated every existing API and Ads Distribution Agreement and *\"fully decommissioned\"* current integrations. After 30 June, calls to the Tenor API endpoints (`tenor.googleapis.com/v2`, and the legacy `g.tenor.com/v1` / `api.tenor.com/v1`) no longer return results, so any GIF picker or bot built on them shows nothing or errors. This is easy to miss because the code often keeps running — it just quietly returns no GIFs — and because Tenor itself did not go away: Google explicitly kept Tenor content working inside its *own* products (Gboard, Tenor.com, the Android/iOS GIF Keyboard, Google Chat and Google Messages). Only third-party API access was withdrawn. Google published no in-product migration path and named no replacement.", "migration": "There is no drop-in Google replacement — the API is simply gone, and Tenor content remains available only inside Google's own apps. If your product used the Tenor API, first grep your codebase and config for the API hosts (`tenor.googleapis.com`, `g.tenor.com/v1`, `api.tenor.com/v1`) and any `TENOR_API_KEY` to find every call site; note that media URLs on `media.tenor.com` / `c.tenor.com` are content delivery and separate from the API. The main like-for-like alternative developers moved to is the **GIPHY Developers API**, which offers comparable search/trending/share endpoints (subject to its own rate limits and key approval); some teams switched to Klipy or self-hosted GIF sources instead. Whichever you choose, the switch is a real integration change — new API keys, a new client, and new attribution/branding requirements — not a hostname swap, so budget for testing the picker end to end.", "alternatives": [ "GIPHY Developers API (developers.giphy.com) — the closest like-for-like GIF search/trending/share API", "Klipy or another GIF/clip API, subject to its own terms and limits", "Self-host a curated GIF/sticker set if a full search API is more than you need" ], "detect": [ "text:tenor.googleapis.com", "text:g.tenor.com/v1", "text:api.tenor.com/v1" ], "source": { "url": "https://support.google.com/tenor/answer/10455265", "label": "What'll happen to the Tenor API? — official Google Tenor support notice" }, "updated": "2026-09-06" }, { "id": "codeanywhere-shutdown", "url": "https://lastcall.dev/entries/codeanywhere-shutdown", "title": "Codeanywhere cloud IDE shuts down", "vendor": "Codeanywhere", "what": "Codeanywhere, the browser-based cloud IDE, has shut down: new signups closed and the service went fully offline on 1 July 2026, after which workspaces, containers, and any data left on the platform are no longer accessible", "category": "SaaS", "sunsetDate": "2026-07-01", "status": "passed", "impact": "Codeanywhere was a browser-based cloud IDE / online code editor: you opened a development environment in a tab — a containerized DevBox with SSH, connections to your own VMs, Dropbox and Google Drive integrations, and support for 75+ languages — without installing anything locally. It started in 2009 as PHPanywhere, acquired the Arduino IDE Codebender in 2017, and was one of the tools that made \"code from a Chromebook, a phone, or a borrowed laptop\" a normal thing to do. In the official announcement the team says the classic cloud-IDE form has been overtaken by browser-based \"vibe coding\", and rather than let the product degrade they are winding it down. New signups closed on announcement; the service stayed fully online through 30 June 2026 as an export window; on 1 July 2026 Codeanywhere went offline and workspaces, containers, and any data still on the platform stopped being accessible. Recurring charges were stopped as part of the wind-down, with no billing for time after the service ended. This is a complete service shutdown — there is no reduced tier to fall back to — and because the offline date has now passed, anything not exported before 1 July 2026 is gone.", "migration": "The vendor's guidance was to get your code out before 1 July 2026 in two ways: push any project connected to GitHub, GitLab, Bitbucket, or another remote so your latest commits are safely off-platform, and download anything that lived only inside a Codeanywhere DevBox or container directly to your machine — including hidden files and environment configs, which are the things people miss. That export window has now closed. Going forward, replace the browser-based development environment with another cloud IDE or coding-environment service, or move to a local editor plus a self-hosted dev container. For post-shutdown questions about exports or billing, Codeanywhere pointed users to support@codeanywhere.net.", "alternatives": [ "GitHub Codespaces — cloud dev environments backed by VS Code and devcontainers", "Gitpod — ephemeral, prebuilt cloud development environments from a Git repo", "Coder — self-hostable cloud development environments on your own infrastructure", "Replit / StackBlitz / CodeSandbox — browser-based coding environments for quick or front-end work", "A local editor (VS Code, JetBrains) with a dev container / Dev Containers extension for a reproducible environment" ], "detect": [], "source": { "url": "https://codeanywhere.com/blog/codeanywhere-is-sunsetting", "label": "Codeanywhere is sunsetting — Codeanywhere (official blog announcement)" }, "updated": "2026-08-26" }, { "id": "bitbucket-app-passwords-eol", "url": "https://lastcall.dev/entries/bitbucket-app-passwords-eol", "title": "Bitbucket Cloud removes app passwords", "vendor": "Atlassian", "what": "Bitbucket Cloud ends app passwords entirely, forcing a move to API tokens", "category": "Feature", "sunsetDate": "2026-07-28", "status": "passed", "impact": "App passwords are how a lot of automation authenticates to Bitbucket Cloud: git clone/push over HTTPS, CI/CD jobs, deploy scripts, and third-party integrations that never moved to OAuth. After 28 July 2026 they stop working completely. Anything still authenticating with an app password gets a failed push or a broken pipeline, not a warning — and the controlled brownouts running since June are Atlassian deliberately breaking them in advance so you find out before the hard date.", "migration": "Replace each app password with an API token (Atlassian account settings → API tokens), scope it to what the integration actually needs, and update the stored credential everywhere it lives: git remotes, CI secrets, and any tool config. API tokens add expiry and centralised management, so treat this as a chance to inventory what still holds a Bitbucket credential rather than a one-to-one swap. New app passwords could not be created after 9 September 2025, so any you still rely on are older than that.", "alternatives": [ "Bitbucket Cloud API tokens (the vendor-required replacement)" ], "detect": [], "source": { "url": "https://community.atlassian.com/forums/Bitbucket-articles/Deprecation-notice-Bitbucket-Cloud-app-password-brownout/ba-p/3237429", "label": "Bitbucket Cloud app password brownout schedule and next steps — Atlassian (official)" }, "updated": "2026-07-28" }, { "id": "aws-sagemaker-model-monitor-eol", "url": "https://lastcall.dev/entries/aws-sagemaker-model-monitor-eol", "title": "AWS closes new-customer access to SageMaker Model Monitor", "vendor": "Amazon Web Services", "what": "SageMaker Model Monitor stops accepting new customers and enters maintenance-only mode — no new features", "category": "SaaS", "sunsetDate": "2026-07-30", "status": "passed", "impact": "This is a soft sunset, not a shutdown, and the distinction matters. From 30 July 2026 you can no longer start using SageMaker Model Monitor if you are not already a customer — new customer access closes. If you already run Model Monitor (data-quality, model-quality, bias-drift or feature-attribution drift monitoring schedules), AWS says you \"can continue to use the service as normal,\" so nothing breaks on the date. What ends is the roadmap: AWS \"do not plan to introduce new features,\" only security and availability fixes. So the real deadline is strategic, not operational — any team standing up new drift monitoring on SageMaker should stop and pick the replacement instead of building on a service that is now closed to newcomers and frozen.", "migration": "AWS names the replacement directly: a combination of its open-source SageMaker AI monitoring solutions (published in the aws-samples GitHub organization, built on Evidently AI and SageMaker MLflow), Amazon QuickSight governance dashboards, and Amazon CloudWatch. The open-source solutions cover the same ground — data-quality and model-quality drift, bias drift, feature-attribution drift — plus LLM evaluation and GPU observability, and run inside your own AWS account. The docs include step-by-step guidance for deleting existing Model Monitor schedules (which stops their recurring Processing-Job compute cost) and standing up the Evidently-based batch or real-time pipelines in their place.", "alternatives": [ "Open-source Amazon SageMaker AI monitoring solutions (aws-samples, Evidently AI + MLflow) — the vendor-recommended replacement", "Amazon QuickSight governance dashboards + Amazon CloudWatch anomaly detection" ], "detect": [], "source": { "url": "https://docs.aws.amazon.com/sagemaker/latest/dg/model-monitor-availability-change.html", "label": "SageMaker Model Monitor availability change — docs.aws.amazon.com" }, "updated": "2026-07-30" }, { "id": "adobe-lightroom-api-eol", "url": "https://lastcall.dev/entries/adobe-lightroom-api-eol", "title": "Adobe Lightroom API reaches end-of-life", "vendor": "Adobe", "what": "Adobe retires the Lightroom API (Firefly Services), directing users to Photoshop API v2", "category": "API", "sunsetDate": "2026-07-31", "status": "passed", "impact": "If you call the Lightroom API to do programmatic photo editing — auto-tone, presets, edits applied server-side as part of a pipeline — those calls stop working after 31 July 2026. Adobe warns of \"service disruptions\" for anyone who has not moved by then, so this is a hard cutoff, not a soft deprecation you can sit on.", "migration": "Adobe points everyone to the Photoshop API v2, which absorbs the image-editing surface, and publishes a migration guide alongside the deprecation notice. The two APIs are not drop-in identical — endpoints, request shapes and the editing model differ — so budget this as a rewrite of the integration, not a base-URL swap, and test against v2 before the date rather than after it.", "alternatives": [ "Adobe Photoshop API v2 (the vendor-recommended replacement)" ], "detect": [], "source": { "url": "https://developer.adobe.com/firefly-services/docs/lightroom/getting-started/deprecation-announcement/", "label": "Lightroom API deprecation announcement — developer.adobe.com" }, "updated": "2026-07-31" }, { "id": "coscreen-shutdown", "url": "https://lastcall.dev/entries/coscreen-shutdown", "title": "CoScreen shuts down", "vendor": "Datadog", "what": "CoScreen, the multi-cursor screen-sharing tool Datadog acquired, is discontinued entirely", "category": "SaaS", "sunsetDate": "2026-07-31", "status": "passed", "impact": "CoScreen is a desktop collaboration tool: several people share windows into one session and each gets their own live cursor and keyboard, which is why pairing and incident-response teams picked it over ordinary screen sharing. It stops entirely on 31 July 2026 — not a feature removal, the product. If it is part of how your team debugs production together, that workflow needs a replacement inside a week, and none of the obvious substitutes reproduce the multi-cursor part.", "migration": "Datadog names no successor product and no migration path in the notice, and points users with transition questions at support. Nothing in the notice suggests functionality moves into the Datadog platform, so treat this as a removal rather than a merge. Teams that relied specifically on simultaneous remote control — rather than one person sharing and everyone else watching — should test replacements before the date, not after: this is the capability least likely to survive the switch.", "alternatives": [ "Tuple (multi-cursor remote pairing, paid)", "Pop (formerly Screen)", "Zoom / Google Meet screen share with remote control — single controller only, not equivalent" ], "detect": [], "source": { "url": "https://www.coscreen.co", "label": "Deprecation notice — coscreen.co" }, "updated": "2026-07-31" }, { "id": "mongodb-8-2-eol", "url": "https://lastcall.dev/entries/mongodb-8-2-eol", "title": "MongoDB 8.2 end-of-life", "vendor": "MongoDB", "what": "MongoDB 8.2 reaches end-of-life", "category": "Runtime", "sunsetDate": "2026-07-31", "status": "passed", "impact": "MongoDB 8.2 was a rapid release, not a long-term one, and its support window closes about ten months after it shipped. After the date, 8.2 receives no further patches — including security patches. If you took 8.2 to get a specific feature, this is the short leash that came with it.", "migration": "Move to MongoDB 8.0, the long-term release on the same major version (supported to 31 October 2029), or forward to a newer rapid release. Upgrades within the 8.x line are the ordinary binary-swap-and-set-FCV procedure rather than a migration, but verify your feature compatibility version after the move.", "alternatives": [ "MongoDB 8.0 (long-term support, to 2029-10-31)", "MongoDB 8.3 (rapid release)" ], "detect": [ "image:mongo:8.2", "image:mongodb/mongodb-community-server:8.2" ], "source": { "url": "https://www.mongodb.com/legal/support-policy/lifecycles", "label": "MongoDB Software Lifecycle Schedules — mongodb.com" }, "updated": "2026-07-31" }, { "id": "rabbitmq-4-2-community-support-end", "url": "https://lastcall.dev/entries/rabbitmq-4-2-community-support-end", "title": "RabbitMQ 4.2 community support ends", "vendor": "RabbitMQ", "what": "RabbitMQ 4.2 stops receiving free community releases", "category": "Runtime", "sunsetDate": "2026-07-31", "status": "passed", "impact": "Community support for the 4.2 series ends: no further free patch releases, including security ones. The series is not dead — commercial extended support runs to 30 June 2030 — so this is a date that costs money rather than one that breaks things. Open-source users are the ones affected.", "migration": "Upgrade to RabbitMQ 4.3, which carries community support to 30 November 2026. Within the 4.x line this is a rolling upgrade rather than a migration; check the release notes for feature-flag requirements before starting, since RabbitMQ gates some upgrades on required feature flags being enabled first.", "alternatives": [ "RabbitMQ 4.3 (community support to 2026-11-30)", "Commercial extended support for 4.2 (to 2030-06-30)" ], "detect": [ "image:rabbitmq:4.2" ], "source": { "url": "https://www.rabbitmq.com/release-information", "label": "Release Information — rabbitmq.com" }, "updated": "2026-07-31" }, { "id": "new-email-shutdown", "url": "https://lastcall.dev/entries/new-email-shutdown", "title": "Resend shuts down new.email", "vendor": "Resend", "what": "new.email, Resend's standalone AI tool for generating email templates from natural-language prompts, is being shut down, with its capabilities folded into the main Resend product", "category": "SaaS", "sunsetDate": "2026-08-07", "status": "passed", "impact": "new.email was a standalone product from Resend: describe an email in plain language and it generated a template you could export. Resend is closing it on 7 August 2026. Until that date the site still works and you can export your templates; after it, the platform stops accepting new prompts and sends. This is a narrow shutdown — the AI-template capability is not disappearing, it is moving into Resend's main email editor — but anyone who built templates in new.email and has not pulled them out has a hard deadline to do so. The one thing genuinely at risk is unexported work: the notice is explicit that access ends on the date, so treat 7 August as the last day to retrieve anything you want to keep.", "migration": "Export your templates from new.email before 7 August 2026 — the notice frames export as the action to take before access ends. The functionality itself continues inside the main Resend product, whose editor now offers brand extraction from a URL, AI block rewriting, LLM content review and generation through the Resend MCP server, so ongoing template work moves there rather than to a third party. Resend says teams that need help migrating can contact them directly. If you only ever used new.email to produce a template and then sent through your own stack, the only migration step that matters is the export; if you relied on it as a live tool, plan to shift that workflow into the Resend editor.", "alternatives": [ "Resend's main email editor (the named successor; AI block rewriting, brand extraction, MCP-based generation)" ], "detect": [], "source": { "url": "https://resend.com/blog/sunsetting-new-email", "label": "Sunsetting new.email — Resend blog (official)" }, "updated": "2026-08-08" }, { "id": "chatgpt-atlas-shutdown", "url": "https://lastcall.dev/entries/chatgpt-atlas-shutdown", "title": "OpenAI shuts down the ChatGPT Atlas browser", "vendor": "OpenAI", "what": "The standalone ChatGPT Atlas browser stops working; agentic browsing folds into ChatGPT", "category": "Browser", "sunsetDate": "2026-08-09", "status": "passed", "impact": "Atlas was OpenAI's standalone AI browser, launched in October 2025 and pitched as a new way to work on the web. Less than a year later it stops working on 9 August 2026. Anyone who moved bookmarks, logins, or a browsing workflow into Atlas is affected, and the sharp edge is data: Atlas browser data — bookmarks, open tabs, and browsing history — does not transfer automatically. On 9 August the app stops opening, so anything you have not exported by then is gone. (ChatGPT conversation history is separate and stays in your ChatGPT account.)", "migration": "Before 9 August 2026, export what you want to keep: cookies and passwords can be moved into the ChatGPT desktop app, and bookmarks can be exported to Chrome. Save any important pages or URLs from your open tabs and history manually, because none of that carries over on its own. Going forward, the browser-based agentic capability moves into ChatGPT itself — OpenAI says it is bringing a more capable in-app browser (multiple tabs, downloads, improved navigation, account login where available) into ChatGPT and Codex — plus a ChatGPT extension for Chrome.", "alternatives": [ "ChatGPT desktop app with the built-in browser (OpenAI's designated successor)", "The ChatGPT extension for Chrome", "Any standalone browser (Chrome, etc.) for general web use" ], "detect": [], "source": { "url": "https://help.openai.com/en/articles/20001371-evolving-atlas-into-chatgpt-for-browser-based-agentic-work", "label": "Evolving Atlas into ChatGPT for browser-based agentic work — OpenAI Help Center (official)" }, "updated": "2026-08-10" }, { "id": "rails-7-2-eol", "url": "https://lastcall.dev/entries/rails-7-2-eol", "title": "Rails 7.2 reaches end of security support", "vendor": "Ruby on Rails", "what": "Rails 7.2 stops receiving security patches — the end of its two-year maintenance window", "category": "Runtime", "sunsetDate": "2026-08-09", "status": "passed", "impact": "After 9 August 2026, Rails 7.2 receives no further security releases. Its bug-fix window already closed on 9 August 2025; security-only support ends exactly two years after the 7.2.0 release. In practice that means a security fix landing in the Rails 8.x line after that date will not be backported to 7.2, so an app pinned to 7.2 accumulates unpatched vulnerabilities in the framework itself. Nothing stops your app from running on 10 August — this is not a service switch-off — but it moves off the supported track, which matters most for anything internet-facing or handling user data.", "migration": "Rails ships supported releases on a fixed schedule: starting with 7.2, each minor release (7.2, 8.0, 8.1, …) gets one year of bug fixes and two years of security fixes from its release date. Getting back onto a supported line means upgrading off 7.2 to a current release — Rails 8.x — following the official upgrade guide, which documents the framework changes and deprecations between versions. Rails upgrades are stepwise by design (bump one minor at a time, run the app's test suite, address deprecation warnings surfaced by the previous version), so budget it as a planned upgrade rather than a same-day swap.", "alternatives": [ "Upgrade to a supported Rails 8.x release (the current maintained line)" ], "detect": [], "source": { "url": "https://rubyonrails.org/maintenance", "label": "Rails maintenance policy — rubyonrails.org" }, "updated": "2026-08-10" }, { "id": "google-content-api-shopping-eol", "url": "https://lastcall.dev/entries/google-content-api-shopping-eol", "title": "Google is sunsetting the Content API for Shopping", "vendor": "Google", "what": "Google will sunset the Content API for Shopping on 18 August 2026, replacing it with the newer Merchant API", "category": "API", "sunsetDate": "2026-08-18", "status": "passed", "impact": "The Content API for Shopping (v2.1) is how merchants and the platforms serving them programmatically manage Google Merchant Center — product listings, inventory, prices, promotions, and account data behind Google Shopping and free product listings. Google will sunset it on 18 August 2026 in favor of the new Merchant API. After the sunset, integrations that still call the old Content API endpoints stop functioning, which for a store means its catalog stops syncing to Merchant Center — a directly revenue-affecting outage. E-commerce platforms, feed-management and product-data tools, and any custom catalog-sync integration are affected.", "migration": "Move to the Merchant API. Google restructured the single Content API surface into several resource-specific sub-APIs (products, inventories, accounts, reporting, and more), so migration is an endpoint-by-endpoint remapping of your calls plus a re-test of the full feed-sync flow, rather than a one-line change. Google offers an extension-request process for teams that need additional time past the sunset date. Because a broken catalog sync stops products from appearing on Google Shopping, start the port well before 18 August 2026 and validate against live Merchant Center data.", "alternatives": [ "Google Merchant API — the official successor Google directs Content API users to" ], "detect": [], "source": { "url": "https://developers.google.com/shopping-content/guides/quickstart", "label": "Content API for Shopping — Google for Developers (official)" }, "updated": "2026-08-18" }, { "id": "openai-assistants-api-eol", "url": "https://lastcall.dev/entries/openai-assistants-api-eol", "title": "OpenAI is retiring the Assistants API", "vendor": "OpenAI", "what": "OpenAI has deprecated the Assistants API and will remove it from the platform on 26 August 2026, directing developers to the newer Responses API", "category": "API", "sunsetDate": "2026-08-26", "status": "passed", "impact": "The Assistants API — the assistants, threads, and runs objects plus the built-in file_search and code_interpreter tools — is the framework a large number of teams built agent, chatbot, and document-QA features on after it launched in 2023. OpenAI deprecated it on 26 August 2025 and set 26 August 2026 as the day it is removed from the platform. Deprecated means it keeps working until then; on the shutdown date, calls to the /v1/assistants, /v1/threads, and related endpoints stop responding. Any product that stores conversation state as OpenAI-hosted Threads, or defines a bot's behavior and tools through an Assistant object, breaks on that date unless it has been migrated. Nothing changes the day you read this — the one-year window from the 2025 announcement is the runway to move.", "migration": "OpenAI's designated successor is the Responses API, and this is a genuine re-architecture rather than a find-and-replace. The Assistants API is stateful in a particular way: OpenAI persists your Assistant, Thread, and Run objects and you reference them by ID. The Responses API models the same capabilities — tool use, file search, code execution, multi-turn state — through a different, single-endpoint shape, so porting means rebuilding how you manage conversation state and re-wiring each built-in tool, not swapping a string. Budget real engineering time, migrate behind the same product surface, and validate well before 26 August 2026 rather than treating it as a last-minute cutover. Teams unwilling to track OpenAI's platform cadence can evaluate other agent frameworks, but that is a larger move than adopting the Responses API.", "alternatives": [ "OpenAI Responses API — the official successor OpenAI points Assistants users to" ], "detect": [ "text:beta.assistants", "text:/v1/assistants", "text:/v1/threads" ], "source": { "url": "https://developers.openai.com/api/docs/deprecations", "label": "Deprecations — OpenAI API (official)" }, "updated": "2026-08-26" }, { "id": "convictional-shutdown", "url": "https://lastcall.dev/entries/convictional-shutdown", "title": "Convictional shuts down its B2B trade platform", "vendor": "Convictional", "what": "Convictional, the B2B trade-enablement and dropship network that connects retailers and suppliers, ends all platform access; integrations and inventory syncing stop and customers must export their data", "category": "SaaS", "sunsetDate": "2026-08-27", "status": "passed", "impact": "Convictional is a B2B trade-enablement network: it lets retailers onboard dropship and wholesale suppliers and automates the order, catalogue, and live-inventory syncing between them, with suppliers connecting via API, EDI, CSV, or SFTP and pre-built connectors for Shopify, Shopify Plus, Magento, BigCommerce, and WooCommerce. Founder Roger Kirkness has announced the company is winding down, citing insufficient product-market fit rather than a lack of runway. The announcement states the last day of platform access is 27 August; because access is still live now, that is 27 August 2026. On that date the platform stops: any retailer or supplier that routes dropship or wholesale orders through Convictional, or depends on its live inventory feeds and pre-built e-commerce connectors, loses that automation and the connection between their systems. This is a full service shutdown, not a feature removal — there is no reduced tier to fall back to.", "migration": "Export first. Convictional has given customers access to download their data and points to a Migration FAQ for the export procedure; do that well before 27 August 2026, because access ends that day. Then re-establish the supplier/retailer connections elsewhere: move to another dropship / B2B trade-automation network, or replace the automation with direct EDI or API integrations to each trading partner. Whichever path you choose, budget time to re-map product catalogues and re-test inventory and order syncing before the cutoff, since orders in flight after that date will not move through Convictional.", "alternatives": [ "Another dropship / B2B trade-automation network (e.g. Modern Dropship, Logicbroker, CommerceHub/Dsco, SPS Commerce) — evaluate against your connectors and partners", "Direct EDI or API integrations between each retailer and supplier", "Your e-commerce platform's native supplier/dropship apps (Shopify, BigCommerce, etc.)" ], "detect": [], "source": { "url": "https://get.convictional.com/posts/convictional-is-shutting-down/", "label": "Convictional is shutting down — Convictional (official announcement, founder Roger Kirkness)" }, "updated": "2026-08-11" }, { "id": "oci-devops-oracle-linux-7-eol", "url": "https://lastcall.dev/entries/oci-devops-oracle-linux-7-eol", "title": "OCI DevOps ends support for Oracle Linux 7 build runners", "vendor": "Oracle", "what": "Oracle Cloud Infrastructure's DevOps service is ending support for Oracle Linux 7 build runners. From 28 August 2026, you can no longer create or run builds on OL7-based build runners in OCI DevOps. This affects the managed CI/CD build service only — it is not the end of the Oracle Linux 7 operating system, which stays on Extended Support until 2028.", "category": "Feature", "sunsetDate": "2026-08-28", "status": "passed", "impact": "OCI DevOps is Oracle Cloud Infrastructure's managed CI/CD service, and one of the things it lets you choose is the operating-system image your build pipeline runs on — a \"build runner.\" Oracle is removing Oracle Linux 7 as an option for those build runners. Its own service-changes notice states plainly: \"Effective August 28, 2026, the support for Oracle Linux 7 comes to an end, after which users can't create or run builds on OL7-based build runners.\" So if you have OCI DevOps build pipelines pinned to an OL7 runner, those builds stop working on 28 August 2026. The scope is worth being precise about, because \"Oracle Linux 7 end of support, August 2026\" is easy to misread as the whole distribution being retired — it is not. This notice is specifically about the OL7 build-runner image inside OCI DevOps. The Oracle Linux 7 OS itself moved from Premier to Extended Support at the start of 2025 and, per Oracle's Lifetime Support Policy, has Extended Support available into 2028 — so your OL7 servers are not affected by this date; only your OCI DevOps build pipelines are.", "migration": "If you use OCI DevOps, audit your build pipelines for any that specify an Oracle Linux 7 build runner and switch them to an Oracle Linux 8 (or newer) runner before 28 August 2026. Oracle's own guidance in the notice is to migrate to Oracle Linux 8, and it advised doing so early — it flagged that OL7-based build-runner launches would see added latency ahead of the hard cutoff, so treat the 28 August date as the point builds stop, not the point to start planning. This is a build-configuration change, not an application migration: your code and your OL7 servers are untouched; what changes is the OS image your CI/CD builds run on. If your build steps depend on something specific to the OL7 image, test those steps on OL8 as part of the switch.", "alternatives": [ "Oracle Linux 8 (or newer) build runners in OCI DevOps — the vendor-named replacement image for build pipelines" ], "detect": [], "source": { "url": "https://docs.oracle.com/en-us/iaas/Content/servicechanges.htm", "label": "OCI service changes — Oracle Cloud Infrastructure documentation (official)" }, "updated": "2026-08-28" }, { "id": "github-classroom-deprecated", "url": "https://lastcall.dev/entries/github-classroom-deprecated", "title": "GitHub Classroom is deprecated — the website, APIs, and services were decommissioned on 28 August 2026", "vendor": "GitHub", "what": "GitHub Classroom is deprecated as of 28 August 2026 in favor of GitHub's selected partner solutions. The GitHub Classroom website, APIs, and related services have been decommissioned. User accounts, repositories, and organizations created to work with Classroom are unaffected, but some Classroom-only data — classroom and assignment names, tests defined outside of repositories, and LTI-integrated rosters — will be permanently deleted under GitHub's data-retention policies. This completes a transition GitHub announced on 26 May 2026, when new sign-ups ended.", "category": "SaaS", "sunsetDate": "2026-08-28", "status": "passed", "impact": "GitHub Classroom was GitHub's free tool for running programming courses on top of GitHub: teachers created assignments backed by template repositories, students accepted them into their own repos, and autograding ran tests against submissions. As of 28 August 2026 that product is gone — GitHub's changelog states the \"website, APIs, and related services have now been decommissioned,\" so the classroom.github.com interface, the assignment/autograding automation, and any integration calling the Classroom API stop working. The good news, stated plainly, is that the GitHub side is untouched: \"any GitHub user accounts, repositories, and organizations created to work with Classroom are not affected\" — student work already in repos stays where it is. What disappears is the Classroom layer on top: GitHub says some data — \"classroom and assignment names, tests defined outside of repositories, and LTI integrated rosters\" — will be permanently deleted per its data-retention policies. So if your course roster lived in an LTI integration, or your autograding tests were defined in Classroom rather than committed to the assignment repos, those are the pieces that vanish rather than migrate. This landed on a short timeline for educators: sign-ups already ended on 26 May 2026, and the full decommission followed on 28 August, right as many institutions were setting up for the autumn term.", "migration": "The repositories are safe; the Classroom scaffolding around them is not, so the migration is about capturing anything that lived only inside Classroom before it is deleted. First, export or note your rosters and assignment structure now — LTI-integrated rosters and assignment names are called out as data that will be permanently deleted, so if you need the mapping of students to repositories, record it while you still can. Second, make sure any autograding tests you relied on are committed into the assignment repositories themselves rather than defined in the Classroom UI (\"tests defined outside of repositories\" are among the data being deleted); tests already in the repos survive because the repos survive. Third, choose a replacement course workflow before the next term: GitHub points educators to its \"selected partner solutions\" and directs course staff to the GitHub Educator Community Discussion for the recommended options and transition guidance. If you prefer to stay on plain GitHub, GitHub Actions can reproduce autograding (run your test suite on push) and a GitHub organization with per-student repositories can reproduce the assignment-distribution pattern without the Classroom layer.", "alternatives": [ "GitHub's selected partner solutions for course management — listed in the GitHub Educator Community Discussion linked from the deprecation notice", "Plain GitHub with GitHub Actions for autograding (run your test suite on each push) plus a GitHub organization holding one repository per student, reproducing assignment distribution without Classroom", "A general education/LMS platform (e.g. an institutional LMS, or tools like Gradescope) for rosters and grading, with student code still hosted in GitHub repositories" ], "detect": [], "source": { "url": "https://github.blog/changelog/2026-08-27-github-classroom-deprecated", "label": "GitHub Changelog — \"GitHub Classroom deprecated\" (official)" }, "updated": "2026-08-29" }, { "id": "flowise-shutdown", "url": "https://lastcall.dev/entries/flowise-shutdown", "title": "Flowise winds down: code freeze now, repo archived 10 August, end-of-life 31 August 2026", "vendor": "Flowise", "what": "Flowise, the open-source low-code builder for LLM apps and agents, is shutting down — the team has frozen development, will archive the GitHub repository on 10 August 2026, and marks the project end-of-life on 31 August 2026", "category": "SaaS", "sunsetDate": "2026-08-31", "status": "passed", "impact": "Flowise is the drag-and-drop tool many teams use to build chatbots, RAG pipelines, and agent workflows on top of LLMs, either self-hosted or through its cloud. The maintainers have announced they are winding down operations, on a dated schedule: a 29 July 2026 announcement and code freeze (feature development stops), a 10 August 2026 repository archival (the GitHub repo moves to read-only, with issues and pull requests locked), and a 31 August 2026 end-of-life. Nothing switches off the instant you read this — a self-hosted Flowise deployment keeps running, and the Apache-2.0 code stays downloadable and forkable indefinitely — but from 10 August the project is frozen: no more fixes, no security patches, and the npm packages and Docker images are marked deprecated. That is the risk to plan around. A stack that leans on Flowise for anything production-facing is now sitting on an unmaintained dependency, so any future bug or CVE in Flowise or its dependency tree is yours to patch, on a fork, with no upstream. The cloud side is the harder deadline: treat 31 August as the point to have exported anything you need out of a hosted account, since the page does not commit to what happens to hosted data or deployments after that.", "migration": "There is no vendor-provided successor and no automated migration path — the team explicitly points teams to self-reliance rather than a replacement product. If you self-host and want to keep using Flowise, fork the repository before the 10 August archival while issues and history are still fully accessible, pin your Docker image and npm versions, and plan to maintain security patches yourself or adopt a community-led fork if a credible one emerges. If you would rather leave the ecosystem, the workflow (nodes for models, retrievers, memory, tools) maps onto other visual LLM builders and onto code-first agent frameworks, but none of them import a Flowise flow directly, so budget for rebuilding the graph rather than a one-click transfer. Whichever path you take, the useful window is now, while the repo is still live and you can read the source and issues.", "alternatives": [ "Fork the Apache-2.0 repository and self-maintain, or join a community-led fork if one forms", "Other visual LLM-app builders (e.g. Langflow, Dify) — comparable node-based flows, but a Flowise graph must be rebuilt, not imported", "Code-first agent/orchestration frameworks for teams ready to move off low-code entirely" ], "detect": [ "npm:flowise", "image:flowiseai/flowise" ], "source": { "url": "https://flowiseai.com/sunset", "label": "Winding down Flowise — flowiseai.com/sunset (the maintainers)" }, "updated": "2026-08-31" }, { "id": "github-spark-shutdown", "url": "https://lastcall.dev/entries/github-spark-shutdown", "title": "GitHub Spark is being retired — export your apps by 31 August 2026", "vendor": "GitHub", "what": "GitHub is deprecating GitHub Spark, its prompt-to-app builder on github.com. As of 4 August 2026 it no longer accepts new users or new app creation; existing users have until 31 August 2026 to open Spark and export their app code before access ends.", "category": "SaaS", "sunsetDate": "2026-08-31", "status": "passed", "impact": "GitHub Spark was GitHub's \"describe it and it builds it\" tool: you wrote a prompt and Spark generated, hosted, and let you share a small web app, including AI features through a built-in llm() function. GitHub is now winding it down on github.com. Two dates matter. Since 4 August 2026 Spark has stopped accepting new users and no longer lets anyone create new apps. Then on 31 August 2026, access to Spark itself ends — after that date you can no longer open Spark to edit or export the apps you built there. GitHub says apps you have already deployed will keep running after the retirement, so a live Spark app does not go dark on 31 August; what you lose is the ability to go back into Spark and change or retrieve the source. Separately, GitHub Models — the inference service that powered Spark's llm() function — was retired on 30 July 2026, so any Spark app that calls llm() has already stopped getting AI responses through it. GitHub frames the shutdown as a consolidation: it says the app-building experience Spark offered is now better served by GitHub Copilot in the tools developers already use (VS Code, the Copilot CLI, and the GitHub Copilot app).", "migration": "If you built anything in GitHub Spark you want to keep working on, open it and export the app code before 31 August 2026 — that is the hard deadline, and once it passes you cannot get back into Spark to retrieve it. Deployed apps continue to run, so there is no rush to redeploy, but the editable source lives inside Spark until you export it. If your app used the built-in llm() function, that path is already dead as of the 30 July 2026 GitHub Models retirement: to restore AI features you will need to wire the app to your own inference provider and manage your own API key and billing. For building new small apps from a prompt, GitHub points to Copilot — the agent modes in VS Code, the Copilot CLI, and the GitHub Copilot app — as the replacement workflow.", "alternatives": [ "GitHub Copilot in VS Code, the Copilot CLI, or the GitHub Copilot app — GitHub's named replacement for prompt-driven app building", "Any external LLM API (bring-your-own key and billing) to replace the retired llm() / GitHub Models inference that Spark apps relied on" ], "detect": [], "source": { "url": "https://github.blog/changelog/2026-08-04-upcoming-deprecation-of-github-spark-on-github-com/", "label": "Upcoming deprecation of GitHub Spark on github.com — GitHub Changelog (official)" }, "updated": "2026-08-31" }, { "id": "newrelic-drop-filter-rules-api-eol", "url": "https://lastcall.dev/entries/newrelic-drop-filter-rules-api-eol", "title": "New Relic is ending its NRQL Drop Filter Rules API", "vendor": "New Relic", "what": "New Relic will shut off its NRQL Drop Filter Rules API on 31 August 2026, moving drop-rule management to the Pipeline Cloud Rules API and the Pipeline Control UI", "category": "API", "sunsetDate": "2026-08-31", "status": "passed", "impact": "Drop filter rules let New Relic customers discard unwanted telemetry — noisy logs, metrics, or spans — before it is stored, which is how teams keep ingest costs and clutter under control. New Relic announced on 21 May 2025 that the NRQL Drop Filter Rules API reaches end of life on 31 August 2026 at 16:00 UTC. After that moment, the old API for creating and managing drop rules stops working. Teams that provision drop rules as code — through Terraform, CI pipelines, or NerdGraph automation calling the drop-rules mutations — lose the ability to manage them that way unless they have migrated. Existing rules keep running; what goes away is the programmatic surface for changing them.", "migration": "New Relic directs users to the Pipeline Cloud Rules API for programmatic drop-rule management, and to the centralized Pipeline Control UI for the console workflow. Re-point any infrastructure-as-code, scripts, or automation that create or update drop rules from the old NRQL Drop Filter Rules API to the Pipeline Cloud Rules API, and re-test that rules still apply as intended. This is a management-plane migration — your currently configured rules continue to filter data — so the work is confined to whatever tooling calls the API, but it must be done before 31 August 2026 16:00 UTC.", "alternatives": [ "Pipeline Cloud Rules API — New Relic's successor for programmatic drop-rule management", "Pipeline Control UI — the console workflow for managing drop rules" ], "detect": [], "source": { "url": "https://docs.newrelic.com/eol/2025/05/drop-rule-filter/", "label": "End-of-life announcement — New Relic docs (official)" }, "updated": "2026-08-31" }, { "id": "power-automate-mobile-app-eol", "url": "https://lastcall.dev/entries/power-automate-mobile-app-eol", "title": "Microsoft deprecates the Power Automate mobile app", "vendor": "Microsoft", "what": "The Power Automate mobile app for iOS and Android is deprecated; the app is pulled from the stores and stops getting updates, support, and push notifications", "category": "SaaS", "sunsetDate": "2026-08-31", "status": "passed", "impact": "Effective 31 August 2026, Microsoft deprecates the Power Automate mobile app for iOS and Android. After that date the app is removed from the Apple App Store and Google Play, stops receiving updates and support, no longer receives push notifications (the \"Send me a mobile notification\" action stops delivering to the app), and the iOS/Android home-screen \"run a flow\" widget stops working. The important limit: your automation itself is fine — all existing cloud flows keep running, nothing is modified or disabled, the notification action still exists in the flow designer, and Approvals functionality is unaffected. What breaks is the on-phone experience — anyone who runs button flows, checks flow runs, responds to approvals, or relies on mobile push from the dedicated app has to move to another surface.", "migration": "Microsoft points each use case to an existing replacement. Approvals move to the Approvals app in Microsoft Teams (IT admins should confirm it is not blocked by Teams app-permission policies). Viewing and managing flows, and running instant/button flows, move to the Power Automate portal, which works in a mobile browser (button flows can also run from Power Apps mobile). For push notifications, flow makers should replace \"Send me a mobile notification\" actions with a \"Post message in a chat or channel\" (Teams) or \"Send an email\" action, so recipients get notified via Teams or email instead of the retired app.", "alternatives": [ "Approvals app in Microsoft Teams (for approvals)", "Power Automate portal in a mobile browser (view/manage and run flows)", "Power Apps mobile (run button flows)", "Teams \"Post message\" or \"Send an email\" flow actions (replacing mobile push notifications)" ], "detect": [], "source": { "url": "https://learn.microsoft.com/en-us/power-platform/important-changes-coming", "label": "Important changes (deprecations) coming in Power Platform — Microsoft Learn (official)" }, "updated": "2026-08-31" }, { "id": "delibr-shutdown", "url": "https://lastcall.dev/entries/delibr-shutdown", "title": "Delibr is shutting down — export your documents before 31 August 2026 or lose them", "vendor": "Delibr", "what": "Delibr, the collaborative product-work document tool, is shutting down on 31 August 2026. The app stays fully functional until that date; after it, all data is permanently deleted. Delibr provides an export tool (email + API key) that produces a single JSON file of your teams, collections, and documents with their comments. Billing has already stopped: no subscriptions are charged after July 2026.", "category": "SaaS", "sunsetDate": "2026-08-31", "status": "passed", "impact": "Delibr was a paid SaaS product for collaborative product work — teams wrote and organized documents (with nested structure and comments) into collections, the kind of feature-spec and product-documentation writing product managers do. Delibr's own site now leads with a shutdown notice: \"Delibr is shutting down August 31, 2026.\" The consequence to plan around is blunt and stated plainly on that page: \"After the shutdown date, all data will be permanently deleted.\" Until then the service keeps working normally — \"The application will remain fully functional until the shutdown date\" — so there is no gradual read-only wind-down to warn you; access is full, and then it is gone. If any of your product specs, feature documents, or decision history live in Delibr, they are not migrating anywhere on their own. This is the kind of shutdown that hurts quietly: the tool works right up to the last day, which makes it easy to forget the deletion date until after it has passed.", "migration": "Export your data before 31 August 2026 — this is the one thing that matters, and there is no stated grace period after the date. Delibr provides an export tool that asks for your email and API key (\"Enter your API key and email to get started\") and returns \"a single JSON file containing your teams, collections, and all documents with their full content and comments.\" Do it early rather than on the last day: a single JSON dump per account is easy to run now and impossible to run on 1 September. Because the export is JSON rather than a document format any editor opens, decide before the cutoff where those documents will live next — a product-documentation or wiki tool (Notion, Confluence, Google Docs, or a Markdown repo) — and, if you need the content readable rather than archived, plan the conversion from the JSON while you still have the live app to cross-check against. Billing has already wound down: Delibr states no subscriptions are charged after July 2026, so an active subscription is not what is keeping your data alive — the 31 August deletion applies regardless.", "alternatives": [ "Any product-documentation or collaborative-docs tool for the writing Delibr held — e.g. Notion, Confluence, or Google Docs — chosen before the cutoff so you have somewhere to put the exported content", "A plain Markdown/Git repository if you mainly need the documents preserved and version-controlled rather than a live collaborative editor", "The Delibr JSON export itself, kept as a permanent archive of teams, collections, documents, and comments even if you have not chosen a destination yet" ], "detect": [], "source": { "url": "https://www.delibr.com/", "label": "Delibr shutdown notice — delibr.com (official)" }, "updated": "2026-08-31" }, { "id": "debian-11-bullseye-eol", "url": "https://lastcall.dev/entries/debian-11-bullseye-eol", "title": "Debian 11 \"bullseye\" end-of-life", "vendor": "Debian", "what": "Debian 11 \"bullseye\" reached end-of-life as its Long Term Support (LTS) term ended", "category": "OS", "sunsetDate": "2026-08-31", "status": "passed", "impact": "After 31 August 2026, Debian 11 \"bullseye\" receives no further security updates from either the main security team or the LTS team. Servers, containers, and CI images still on `debian:11` / `debian:bullseye` are now unpatched against new CVEs. Regular security support ended on 14 August 2024; the LTS term extended coverage for two more years, and that has now expired too.", "migration": "Upgrade to Debian 12 \"bookworm\" (supported through June 2028) — or Debian 13 \"trixie\" — with a standard dist-upgrade, and repin any container base images from `debian:11`/`debian:bullseye` to `debian:12`/`debian:bookworm`. Where a longer runway is needed, Freexian's commercial Extended LTS covers bullseye beyond the free LTS window.", "alternatives": [ "Debian 12 \"bookworm\"", "Debian 13 \"trixie\"", "Freexian Extended LTS (commercial)" ], "detect": [ "image:debian:11", "image:debian:bullseye" ], "source": { "url": "https://www.debian.org/releases/bullseye/", "label": "Debian 11 (bullseye) release page — Debian.org" }, "updated": "2026-09-08" }, { "id": "azure-nested-confidential-cc-v5-vms-retirement", "url": "https://lastcall.dev/entries/azure-nested-confidential-cc-v5-vms-retirement", "title": "Azure retires the nested confidential (cc_v5) VM series on 1 September 2026 — resize before then or your VMs are deallocated", "vendor": "Microsoft Azure", "what": "Azure is retiring the nested confidential cc_v5 virtual machine series on 1 September 2026. After that date the cc_v5 series is no longer available for use or purchase, and any affected VM that has not been resized before the cutoff will be deallocated. The impacted VM sizes are DCas_cc_v5, DCads_cc_v5, ECas_cc_v5, and ECads_cc_v5.", "category": "SaaS", "sunsetDate": "2026-09-01", "status": "passed", "impact": "The cc_v5 series is Azure's nested confidential virtual machines — VMs that run inside a confidential host, used for confidential-computing workloads that keep data encrypted in memory. Microsoft's retirement notice states that \"on September 1, 2026, the cc_v5 confidential VM series will be retired and will no longer be available for use or purchase,\" and — the part that bites — \"any affected VM that has not been resized before that date will [be] deallocated.\" So this is not a soft deprecation you can ignore until convenient: a running DCas_cc_v5, DCads_cc_v5, ECas_cc_v5, or ECads_cc_v5 VM that is still on the retired size on 1 September stops. Deallocation means the VM is powered off and its compute released; anything not persisted to managed disks or external storage, and any workload expecting the machine to stay up, is affected. The blast radius is narrow — only subscriptions running these specific nested-confidential sizes — but for those, an unactioned VM is a stopped VM on the date, not merely an unsupported one.", "migration": "Resize every VM on a cc_v5 size to a supported VM series before 1 September 2026 — resizing before the date is the explicit action the notice calls out to avoid deallocation. Identify affected machines by their size (DCas_cc_v5, DCads_cc_v5, ECas_cc_v5, ECads_cc_v5) across your subscriptions, then move each to a current confidential-computing VM series that meets your requirements (check the Azure confidential computing VM options for the current generation, and validate that your workload's memory-encryption and attestation needs are met on the target size). Treat any VM you cannot resize in time as one that will be stopped on the date, and plan for the downtime and data-persistence implications accordingly rather than being surprised by a deallocation.", "alternatives": [ "A current-generation Azure confidential-computing VM series that meets your workload's requirements, chosen from the Azure confidential computing VM options", "Resizing to a supported general-purpose or memory-optimized series if the workload no longer requires nested confidential computing" ], "detect": [], "source": { "url": "https://azure.microsoft.com/updates?id=568661", "label": "Azure Updates — \"Retirement: Nested confidential (cc_v5) VMs will be retired on September 1, 2026\" (official)" }, "updated": "2026-09-01" }, { "id": "surfeasy-vpn-shutdown", "url": "https://lastcall.dev/entries/surfeasy-vpn-shutdown", "title": "SurfEasy VPN is shutting down on 1 September 2026 — the apps and service stop working; eligible users move to Norton VPN", "vendor": "Gen (SurfEasy)", "what": "SurfEasy VPN reaches end of life on 1 September 2026. After that date the SurfEasy apps and services stop working entirely — you cannot access your account, download, activate, connect, or use the app. SurfEasy's owner, Gen (the Norton / Cyber Safety brands family), is retiring it as part of a \"portfolio simplification strategy\" and is offering eligible SurfEasy Legacy and Annual customers Norton VPN at no extra cost, with a product key delivered by email.", "category": "SaaS", "sunsetDate": "2026-09-01", "status": "passed", "impact": "SurfEasy is a consumer VPN app (Windows, macOS, Android, iOS) that has been around for years and shipped bundled with some other products. Its end-of-life notice is blunt about the cutoff: \"After this date, the SurfEasy apps and services will no longer work. i.e., you will not be able to access your account, download, activate, connect, or use the app properly.\" So this is a hard stop, not a wind-down — on 1 September 2026 the app stops routing your traffic and stops authenticating, and any device or router configuration that depends on SurfEasy loses its VPN. SurfEasy's owner, Gen (the family behind Norton and other Cyber Safety brands), frames it as consolidation: the VPN \"is being retired as part of our portfolio simplification strategy, enabling us to concentrate investment on fewer, more powerful VPN products.\" The practical risk is the silent one common to VPN shutdowns: if you rely on SurfEasy for privacy on public Wi-Fi or to reach geo-restricted services, your traffic quietly falls back to an unprotected connection the moment the app stops connecting — so this is worth acting on before the date rather than discovering it when the tunnel simply fails to come up.", "migration": "If you are an eligible SurfEasy Legacy or Annual customer, Gen is offering Norton VPN at no extra cost: watch for a product key delivered by email and activate it before 1 September so you are not left without a VPN when SurfEasy stops. If you would rather not move to Norton VPN — or you are not among the eligible customers — choose and install a replacement consumer VPN before the cutoff and remove SurfEasy from any device or router that still points to it, so nothing silently falls back to an unprotected connection. Either way, do it ahead of the date: because the apps stop working entirely on 1 September, you cannot rely on a grace period to reconnect and finish migrating afterward.", "alternatives": [ "Norton VPN — offered by Gen at no extra cost to eligible SurfEasy Legacy and Annual customers, activated with an emailed product key", "Any other reputable consumer VPN (e.g. Mullvad, Proton VPN, or a provider of your choice) if you prefer not to stay within the Gen/Norton portfolio" ], "detect": [], "source": { "url": "https://surfeasy.zendesk.com/hc/en-us/articles/51856142395924-SurfEasy-VPN-End-of-Life-announcement", "label": "SurfEasy Help Center — \"SurfEasy VPN End-of-Life announcement\" (official)" }, "updated": "2026-09-01" }, { "id": "github-copilot-models-deprecated-sep-2026", "url": "https://lastcall.dev/entries/github-copilot-models-deprecated-sep-2026", "title": "GitHub Copilot deprecates Gemini 3.1 Pro, Claude Opus 4.5/4.6, Claude Sonnet 4.5/4.6 and Raptor Mini", "vendor": "GitHub", "what": "GitHub deprecated six models — Gemini 3.1 Pro, Claude Opus 4.5, Claude Opus 4.6, Claude Sonnet 4.5, Claude Sonnet 4.6 and Raptor Mini — across most GitHub Copilot experiences", "category": "Feature", "sunsetDate": "2026-09-01", "status": "passed", "impact": "On 1 September 2026 GitHub removed six models from most GitHub Copilot experiences — Copilot Chat, inline edits, ask and agent modes, and code completions. The deprecated models and GitHub's suggested replacements are: Gemini 3.1 Pro → Gemini 3.7 Flash; Claude Opus 4.5 → Claude Opus 4.7, 4.8 or 5; Claude Opus 4.6 → Claude Opus 4.7, 4.8 or 5; Claude Sonnet 4.5 → Claude Sonnet 5; Claude Sonnet 4.6 → Claude Sonnet 5; and Raptor Mini → MAI-Code-1.1-Flash. For most people this is a quiet swap — the deprecated option simply disappears from the model picker in VS Code and on github.com and a newer model takes its place, and GitHub says no action is required to remove the old models. It matters to anyone who named one of these models by hand: a workflow, CI step, integration, or script that selects a Copilot model through the API, or an enterprise policy that allow-lists specific models. Those references stop resolving to a live model after the date. One exception: GitHub says Claude Sonnet 4.6 remains available to individual GitHub Copilot subscribers on annual plans.", "migration": "Point any workflow, integration, or configuration that names one of the deprecated models at its suggested replacement: Gemini 3.1 Pro → Gemini 3.7 Flash, Claude Opus 4.5 or 4.6 → Claude Opus 4.7 / 4.8 / 5, Claude Sonnet 4.5 or 4.6 → Claude Sonnet 5, Raptor Mini → MAI-Code-1.1-Flash. Enterprise administrators may need to enable the alternative models through their Copilot model policies in Copilot settings, then confirm each appears in the Copilot Chat model selector in VS Code and on github.com so their users can pick it. Individuals who simply choose a model from the Copilot menu need do nothing. Enterprise customers with questions are directed to their GitHub account manager.", "alternatives": [ "Gemini 3.7 Flash — GitHub's named replacement for Gemini 3.1 Pro", "Claude Opus 4.7, Claude Opus 4.8, or Claude Opus 5 — replacements for Claude Opus 4.5 and 4.6", "Claude Sonnet 5 — replacement for Claude Sonnet 4.5 and 4.6", "MAI-Code-1.1-Flash — replacement for Raptor Mini" ], "detect": [], "source": { "url": "https://github.blog/changelog/2026-08-31-selected-github-copilot-models-deprecated", "label": "Selected GitHub Copilot models deprecated — The GitHub Blog (changelog, 31 August 2026)" }, "updated": "2026-09-02" }, { "id": "openssl-3-0-eol", "url": "https://lastcall.dev/entries/openssl-3-0-eol", "title": "OpenSSL 3.0 end-of-life", "vendor": "OpenSSL", "what": "OpenSSL 3.0, the current long-term-support branch, stops receiving fixes", "category": "Library", "sunsetDate": "2026-09-07", "status": "passed", "impact": "OpenSSL 3.0 is the LTS branch that shipped with a large share of long-lived Linux distributions and vendor appliances, so this is one of the widest-reaching dates on the calendar. After it passes, no further fixes are published for 3.0 — including security fixes. Anything still linked against it keeps working, and that is the danger: nothing breaks visibly, the patches simply stop arriving.", "migration": "Move to a supported branch — 3.5 is the current LTS. If you consume OpenSSL through your distribution rather than directly, the relevant date is usually your distro's, not this one: distributions with their own long support windows (RHEL, Ubuntu LTS) backport fixes into their 3.0 packages beyond upstream EOL. Check whether your vendor does before assuming you are exposed, and check whether it does not before assuming you are safe.", "alternatives": [ "OpenSSL 3.5 (LTS)", "Distribution-backported OpenSSL 3.0, where your vendor offers it" ], "detect": [], "source": { "url": "https://openssl-library.org/policies/releasestrat/", "label": "Release Strategy — openssl-library.org" }, "updated": "2026-09-07" }, { "id": "github-copilot-mai-code-1-flash-deprecation", "url": "https://lastcall.dev/entries/github-copilot-mai-code-1-flash-deprecation", "title": "GitHub Copilot deprecates the MAI-Code-1-Flash model", "vendor": "GitHub", "what": "GitHub removes the MAI-Code-1-Flash model from all GitHub Copilot experiences and directs users to its successor, MAI-Code-1.1-Flash", "category": "Feature", "sunsetDate": "2026-09-10", "status": "passed", "impact": "MAI-Code-1-Flash is one of the models selectable inside GitHub Copilot. On 10 September 2026 GitHub deprecates it across all Copilot experiences — the model selector in VS Code, on github.com, and anywhere else Copilot exposes a model choice. Its replacement is MAI-Code-1.1-Flash. This is a lightweight change for most individual users: GitHub says no action is required to remove the older model once it is deprecated, and existing Copilot functionality continues on the new model. It matters to anyone who has pinned MAI-Code-1-Flash by name — in a workflow, an integration, a script that selects a Copilot model via API, or an enterprise policy that allow-lists specific models. Those references stop resolving to a working model after the date and need to be pointed at MAI-Code-1.1-Flash instead.", "migration": "Before 10 September 2026, update any workflow, integration, or configuration that names MAI-Code-1-Flash to use MAI-Code-1.1-Flash. Enterprise administrators should enable the replacement model in Copilot settings and confirm it appears in the model selector inside VS Code and on github.com so their users can pick it. Individuals who simply select a model from the Copilot menu need do nothing — the old option is removed and the new one is available in its place. Enterprise customers with specific concerns are directed to their GitHub account manager.", "alternatives": [ "MAI-Code-1.1-Flash — the direct, GitHub-named successor model" ], "detect": [ "text:MAI-Code-1-Flash" ], "source": { "url": "https://github.blog/changelog/2026-08-11-upcoming-deprecation-of-mai-code-1-flash", "label": "Upcoming deprecation of MAI-Code-1-Flash — The GitHub Blog (changelog, 11 August 2026)" }, "updated": "2026-09-10" }, { "id": "microsoft-sentinel-sap-connector-agent-retirement", "url": "https://lastcall.dev/entries/microsoft-sentinel-sap-connector-agent-retirement", "title": "Microsoft Sentinel retires the containerized SAP data connector agent", "vendor": "Microsoft", "what": "Microsoft retires the containerized data connector agent for the Microsoft Sentinel solution for SAP applications; the SAP agentless data connector is the replacement", "category": "Feature", "sunsetDate": "2026-09-14", "status": "passed", "impact": "If you feed SAP logs into Microsoft Sentinel through the containerized data connector agent, that pipeline stops on 14 September 2026. Microsoft says the agent is permanently disabled after that date and stops sending SAP logs to Sentinel, so any analytics rules, workbooks, hunting queries, and playbooks that depend on SAP data go dark for the affected systems — a real gap in SIEM and threat-detection coverage for your SAP estate. Creation of new containerized agents is already disabled. Customers who already use the newer SAP agentless data connector are not affected, and there is no change to Sentinel pricing or billing meters.", "migration": "Migrate to the Microsoft Sentinel SAP agentless data connector before 14 September 2026. Microsoft describes a side-by-side cutover with no gap in coverage: deploy the agentless connector alongside your existing containerized agent, validate that SAP logs are being ingested, then decommission the agent. Existing analytics rules, workbooks, and playbooks keep working throughout because the data keeps flowing.", "alternatives": [ "Microsoft Sentinel SAP agentless data connector — generally available, the Microsoft-named replacement" ], "detect": [], "source": { "url": "https://azure.microsoft.com/updates?id=568457", "label": "Retirement: Containerized data connector agent for the Microsoft Sentinel solution for SAP applications — Azure Updates (12 August 2026)" }, "updated": "2026-09-14" }, { "id": "relay-app-shutdown", "url": "https://lastcall.dev/entries/relay-app-shutdown", "title": "Relay.app shuts down", "vendor": "Relay.app", "what": "The Relay.app workflow-automation service closes, on two dates: free accounts first, paid accounts a month later", "category": "SaaS", "sunsetDate": "2026-09-14", "status": "passed", "impact": "Relay.app is a workflow-automation service in the Zapier/Make category, with AI steps and human-in-the-loop approvals as its distinguishing features. It closes on two dates: 15 August 2026 for free users, 14 September 2026 for paying customers. Whichever applies to you is also your export deadline — anything still only inside Relay after that is gone. Subscriptions were already cancelled on 16 July 2026, so paying customers are running on wind-down access, not a live plan.", "migration": "Relay provides exports rather than a migration: workflows, sequences and MCP servers come out as JSON, AI prompts as text, run history and tables as CSV. No competitor imports that JSON directly, so the export is documentation for a rebuild, not a transfer. Export first and rebuild second — the export stops being available on your shutdown date, whereas rebuilding can happen afterwards. Annual customers are receiving prorated refunds, stated as within five business days.", "alternatives": [ "Zapier", "Make", "n8n (self-hostable)", "Windmill (self-hostable)" ], "detect": [], "source": { "url": "https://www.relay.app/", "label": "Shutdown announcement — relay.app" }, "updated": "2026-09-14" }, { "id": "azure-maps-render-v1-api-retirement", "url": "https://lastcall.dev/entries/azure-maps-render-v1-api-retirement", "title": "Azure Maps Render v1 API is retired on 17 September 2026", "vendor": "Microsoft", "what": "Microsoft retires the Azure Maps Render v1 REST API — after 17 September 2026 calls to the Render v1 endpoints stop working and must move to Render v2", "category": "API", "sunsetDate": "2026-09-17", "status": "confirmed", "impact": "Microsoft's Azure Maps Render v1 REST API is deprecated and retires on 17 September 2026. Its own documentation states the Render v1 service \"is now deprecated and will be retired on 9/17/26\" and that all calls to the Render v1 API must be updated to the latest version by that date to avoid service disruptions. This is the API behind server-side map images and tiles — map image, static image, map tile, and imagery calls under the `rest-maps-1.0` API version. After the retirement date, applications still calling Render v1 endpoints lose their map imagery: static maps in reports and emails, cached tile pipelines, and any backend that renders a map server-side will break rather than degrade. A related change lands two days earlier — Microsoft automatically upgrades any remaining Azure Maps Gen1 (S0/S1) accounts to Gen2 on 15 September 2026 — so teams on older Azure Maps accounts are dealing with both a pricing-tier migration and an API retirement in the same week.", "migration": "Move Render v1 calls to the Azure Maps Render v2 API before 17 September 2026. In practice that means updating the API version from `1.0` to the current Render v2 version and adjusting request and response handling to the v2 shapes for the endpoints you use (map image / static image, map tile, imagery). Microsoft positions Render v2 as offering improved data quality and performance. Inventory every place your code or scripts call `atlas.microsoft.com` Render endpoints with the v1 API version, test the v2 responses against what your app expects (image formats, tile addressing, and parameters differ in places), and cut over before the date. Separately, confirm whether your Azure Maps account is Gen1 — if so, plan for the automatic Gen2 upgrade on 15 September 2026 and review the Gen2 pricing model.", "alternatives": [ "Azure Maps Render v2 API — the direct replacement, with improved data quality and performance per Microsoft" ], "detect": [], "source": { "url": "https://learn.microsoft.com/en-us/rest/api/maps/render/get-map-image?view=rest-maps-1.0", "label": "Azure Maps Render v1 — Get Map Image REST API — learn.microsoft.com (official retirement notice)" }, "updated": "2026-09-03" }, { "id": "openai-sora-2-video-api-shutdown", "url": "https://lastcall.dev/entries/openai-sora-2-video-api-shutdown", "title": "OpenAI shuts down the Sora 2 video models and the Videos API", "vendor": "OpenAI", "what": "OpenAI is removing its Sora 2 video-generation models and the Videos API from the platform — sora-2, sora-2-pro and their dated snapshots stop responding, with no direct replacement named", "category": "API", "sunsetDate": "2026-09-24", "status": "confirmed", "impact": "On 24 March 2026 OpenAI deprecated its Sora 2 video models and set 24 September 2026 as the date they — and the Videos API that serves them — are removed from the platform. The affected identifiers are sora-2, sora-2-pro, and the dated snapshots sora-2-2025-10-06, sora-2-2025-12-08 and sora-2-pro-2025-10-06. Unlike OpenAI's audio and Assistants deprecations, this one names no replacement model: the documentation lists no substitute, so this is a capability being withdrawn from the API, not a version bump. Anything that calls the Videos API — an app that generates clips on demand, a pipeline that renders video from prompts, a feature built on sora-2 — starts failing on the shutdown date and there is no OpenAI endpoint to point it at afterward. Deprecated models keep working until then, so nothing breaks the day you read this, but the runway is finite and there is no in-platform landing spot at the end of it.", "migration": "There is no like-for-like OpenAI replacement, so plan for a provider change rather than a model rename. If your product depends on generating video via the Videos API, evaluate other text-to-video providers and budget for the larger integration work that a different API and output format imply — this is not a one-line model-string swap like the audio-model deprecations. If the generated video is a convenience feature rather than the core of the product, the cheaper path may be to remove or gate it before the shutdown date so it fails gracefully instead of erroring. Either way, the useful thing to lock in now is the date: 24 September 2026 is when calls stop being answered.", "alternatives": [ "Third-party text-to-video providers (OpenAI names no in-platform replacement)", "Removing or gating the video feature before the shutdown date, if it is non-core" ], "detect": [ "text:sora-2", "text:sora-2-pro", "text:sora-2-2025-10-06", "text:sora-2-2025-12-08", "text:sora-2-pro-2025-10-06" ], "source": { "url": "https://developers.openai.com/api/docs/deprecations", "label": "Deprecations — OpenAI API (official)" }, "updated": "2026-07-30" }, { "id": "cloudflare-legacy-registrar-api-eol", "url": "https://lastcall.dev/entries/cloudflare-legacy-registrar-api-eol", "title": "Cloudflare retires the legacy Registrar API — the /registrar/domains endpoints reach end-of-life 27 September 2026", "vendor": "Cloudflare", "what": "The legacy Cloudflare Registrar domain-management API paths (/accounts/{account_id}/registrar/domains) stop working; automation that manages Cloudflare-registered domains must move to the new Registrar API", "category": "API", "sunsetDate": "2026-09-27", "status": "confirmed", "impact": "This affects anything that manages Cloudflare Registrar domains through Cloudflare's REST API on the older path — infrastructure-as-code, domain-portfolio automation, billing/renewal scripts, and any custom tooling that calls the legacy /accounts/{account_id}/registrar/domains endpoints. Per Cloudflare's own deprecations page, the legacy Registrar API was deprecated on 10 April 2026 and reaches end-of-life on 27 September 2026, after which those calls are no longer supported. The Registrar feature itself is not going away — Cloudflare has published a new Registrar API in its place, with endpoints for domain search, availability checking, registration, and management. As with Cloudflare's other endpoint retirements, the sharp edge is unattended automation: a dashboard user renewing a domain by hand sees nothing change, but a script that lists or updates domains by hitting the old URL will start returning errors on the date. Anyone who registers or transfers domains through Cloudflare Registrar and drives it via the API should assume they are in scope until they have checked.", "migration": "Move any code that calls /accounts/{account_id}/registrar/domains to the new Registrar API (developers.cloudflare.com/api/resources/registrar/). Because the new API is a re-shaped resource rather than a pure path rename, budget a little more than a find-and-replace: confirm the request and response shapes for the operations you use (listing domains, reading a domain, updating auto-renew or nameserver settings) against the new reference, then update generated clients, vendored wrappers, and any Terraform or CI steps that touch domains. Do it before 27 September 2026. This is one of a cluster of endpoint end-of-life dates Cloudflare lists on the same page — if you authenticate API calls with the legacy X-Auth-User-Service-Key header, note the separate Service Key authentication retirement on 30 September 2026, three days later.", "alternatives": [ "The new Cloudflare Registrar API at developers.cloudflare.com/api/resources/registrar/ (domain search, availability, registration, and management)", "Manage domains through the Cloudflare dashboard, which is unaffected by this API path retirement" ], "detect": [ "text:/registrar/domains" ], "source": { "url": "https://developers.cloudflare.com/fundamentals/api/reference/deprecations/", "label": "Cloudflare API deprecations — developers.cloudflare.com (official)" }, "updated": "2026-08-30" }, { "id": "azure-automation-python-powershell-runtime-retirement", "url": "https://lastcall.dev/entries/azure-automation-python-powershell-runtime-retirement", "title": "Azure Automation retires Python 2.7, Python 3.8, and PowerShell 7.1/7.2 runbook runtimes", "vendor": "Microsoft", "what": "Azure Automation ends support for the Python 2.7, Python 3.8, PowerShell 7.1, and PowerShell 7.2 runbook runtime versions", "category": "Runtime", "sunsetDate": "2026-09-30", "status": "confirmed", "impact": "If you run Azure Automation runbooks on the Python 2.7, Python 3.8, PowerShell 7.1, or PowerShell 7.2 runtime, those versions lose support on 30 September 2026. Microsoft says the runbooks may keep running after that date, but they will no longer receive security updates, bug fixes, or official support — so anything left on these runtimes becomes an unpatched, unsupported liability in your automation estate. This is a forced runtime upgrade rather than a hard shutoff: nothing is deleted on the day, but staying put means running security-critical automation on runtimes Microsoft no longer maintains.", "migration": "Before 30 September 2026, re-target affected runbooks to a supported Python or PowerShell runtime version in Azure Automation. Microsoft points to its PowerShell support lifecycle and Python version support guidance to choose a supported target, then recommends testing each runbook on the newer runtime before cutting over. Because the old runtimes keep executing for now, you can migrate and validate runbook-by-runbook rather than in a single big-bang cutover.", "alternatives": [ "Supported Azure Automation runbook runtimes — newer Python and PowerShell versions still receiving updates (per Microsoft's support-lifecycle guidance)" ], "detect": [], "source": { "url": "https://azure.microsoft.com/updates?id=567556", "label": "Retirement: Support for Python 2.7, 3.8 and PowerShell 7.1, 7.2 will be retired on September 30, 2026 — Azure Updates (id 567556)" }, "updated": "2026-08-14" }, { "id": "amazon-mechanical-turk-shutdown", "url": "https://lastcall.dev/entries/amazon-mechanical-turk-shutdown", "title": "Amazon Mechanical Turk (MTurk) is shutting down", "vendor": "Amazon Web Services", "what": "Amazon will permanently close Amazon Mechanical Turk (MTurk) — the crowdsourcing marketplace and MTurk API for Human Intelligence Tasks — on 30 September 2026, and the same closure ends SageMaker Ground Truth and Amazon Augmented AI (A2I) human-review workflows", "category": "API", "sunsetDate": "2026-09-30", "status": "confirmed", "impact": "Amazon Mechanical Turk (MTurk) is the on-demand human workforce behind a huge amount of data labeling, survey collection, content moderation, and evaluation work: requesters post Human Intelligence Tasks (HITs) and workers complete them, driven programmatically through the MTurk API (the `mturk` boto3 client and the `mturk-requester` endpoint). Following an assessment, AWS has decided to close it permanently on 30 September 2026. New customer registration already stopped on 30 July 2026. On the closure date HIT submission ends and all remaining unsubmitted HITs automatically expire, so any pipeline — nightly data-labeling jobs, RLHF/eval loops, academic studies, moderation queues — that calls the MTurk API for human work stops returning results that day. The blast radius is wider than the marketplace: the closure also ends the Amazon Mechanical Turk Worker type in SageMaker Ground Truth labeling jobs and Amazon Augmented AI (A2I) human-review workflows as of 30 September 2026, so ML teams who never touched the MTurk console directly are affected too. Money and records wind down on their own clock: requesters can award bonuses and approve or reject completed HITs until 30 October 2026 (unactioned HITs auto-approve), pre-paid balances are refunded within 30 days, and transaction history stays available only until 28 January 2027 — pull anything you need for the record before then.", "migration": "There is no in-place successor from AWS — MTurk, SageMaker Ground Truth, and Amazon Augmented AI (A2I) are all closing together, so this is a move off the platform, not an upgrade. First, protect what is owed: workers should verify a payment method and transfer schedule in the MTurk Worker Portal, and requesters should verify payment info in the Requester Portal so refunds process cleanly. Export any HIT data, results, and transaction history you need before 28 January 2027, after which the history is gone. Then re-home the human-in-the-loop work: move data labeling and annotation to another managed crowdsourcing/labeling provider (see alternatives), and if you drive MTurk through the API, plan to rewrite the `mturk` boto3 / MTurk API calls against the new vendor's API — there is no drop-in endpoint. Validate the replacement pipeline on real tasks well before 30 September 2026 rather than treating the cutoff as a switch you flip at the last minute.", "alternatives": [ "Managed data-labeling / annotation platforms (e.g. Scale AI, Labelbox, Appen, Toloka, Prolific for research studies) — evaluate against your task types, quality controls, and API", "Other human-in-the-loop / crowdsourcing marketplaces (e.g. Clickworker, Remotasks) for HIT-style microtasks", "Self-hosted labeling tooling (e.g. Label Studio, CVAT) paired with your own contractor or internal workforce for full control" ], "detect": [ "text:mturk-requester" ], "source": { "url": "https://www.mturk.com/help", "label": "Closure FAQs — Amazon Mechanical Turk (official, mturk.com)" }, "updated": "2026-08-27" }, { "id": "cloudflare-service-key-authentication-eol", "url": "https://lastcall.dev/entries/cloudflare-service-key-authentication-eol", "title": "Cloudflare removes Service Key authentication — the X-Auth-User-Service-Key header stops working 30 September 2026", "vendor": "Cloudflare", "what": "Cloudflare retires Service Key API authentication; requests using the X-Auth-User-Service-Key header stop being accepted and callers must move to Cloudflare API Tokens", "category": "API", "sunsetDate": "2026-09-30", "status": "confirmed", "impact": "This affects any code or tool that authenticates to the Cloudflare API with a Service Key, sent in the X-Auth-User-Service-Key header. Per Cloudflare's deprecations page, Service Key authentication was deprecated on 19 March 2026 and reaches end-of-life on 30 September 2026; after that date requests using the header are no longer authenticated, and new Service Keys can no longer be generated from the dashboard or API. Service Keys were most often used for a narrow set of operations such as issuing origin CA certificates, so the highest-risk callers are automation around origin certificates and any long-lived scripts still carrying the header. Cloudflare specifically calls out users of cloudflared and origin-ca-issuer, telling them to update to versions that use API Tokens. The failure mode is the usual one for an auth retirement: nothing changes until the date, then every request on the old credential starts coming back as an authentication error — so a certificate-issuance job or an integration that has quietly worked for years can break all at once.", "migration": "Switch to Cloudflare API Tokens, which Cloudflare says provide all the functionality of Service Keys plus fine-grained permission scoping, expiration, and IP-address restrictions. Create a token scoped to only the permissions the workload needs, replace the X-Auth-User-Service-Key header with a standard Authorization: Bearer header (or the token field your SDK expects), and remove the old Service Key. If you run cloudflared or origin-ca-issuer, update them to a version that authenticates with API Tokens rather than a Service Key — Cloudflare names both explicitly. Do the swap before 30 September 2026. If you also manage domains through the legacy Registrar API, note its separate end-of-life three days earlier, on 27 September 2026.", "alternatives": [ "Cloudflare API Tokens — the recommended replacement, with scoped permissions, expiration, and IP restrictions (developers.cloudflare.com/fundamentals/api/get-started/create-token/)", "For origin certificates specifically, updated cloudflared and origin-ca-issuer releases that authenticate with API Tokens" ], "detect": [ "text:X-Auth-User-Service-Key" ], "source": { "url": "https://developers.cloudflare.com/fundamentals/api/reference/deprecations/", "label": "Cloudflare API deprecations — developers.cloudflare.com (official)" }, "updated": "2026-08-30" }, { "id": "jetbrains-teacher-pack-bootcamps-sunset", "url": "https://lastcall.dev/entries/jetbrains-teacher-pack-bootcamps-sunset", "title": "JetBrains sunsets the Teacher Pack for Bootcamps — last day to apply 30 September 2026, no new applications from 1 October", "vendor": "JetBrains", "what": "The JetBrains Teacher Pack for Bootcamps — the program that gave bootcamp instructors free JetBrains IDE access and issued student coupons — is being retired; 30 September 2026 is the final application day and no new applications are accepted from 1 October 2026", "category": "Feature", "sunsetDate": "2026-09-30", "status": "confirmed", "impact": "This affects anyone who runs a coding bootcamp and relies on the JetBrains Teacher Pack for Bootcamps to get free JetBrains IDE licenses for instructors and coupons for students. JetBrains says 30 September 2026, 11:59 pm CET is the last day to apply; bootcamps that apply on or before that date receive one final set of student coupons, valid for up to six months. Starting 1 October 2026, JetBrains will no longer accept new applications, will issue no additional student coupons, and instructors will no longer receive free access to JetBrains IDEs through the bootcamp program. Existing coupons already issued continue to work until they expire. This is a discontinuation of one specific free-licensing route, not of JetBrains' education offering as a whole — JetBrains points bootcamps at its other education programs instead.", "migration": "If you run a bootcamp and want one last round of JetBrains IDE access under this program, submit a final application before 30 September 2026, 11:59 pm CET — those coupons stay valid up to six months. For access beyond that, move to one of JetBrains' other education programs (Classroom Assistance, the free Community editions of IntelliJ IDEA and PyCharm, or Student/Teacher licenses where eligible) rather than the retired bootcamp track. Do not assume instructor IDE access renews automatically after 1 October 2026 — plan replacement licensing before your current coupons expire.", "alternatives": [ "JetBrains' other education programs (Classroom Assistance and the broader teaching/learning offerings JetBrains directs bootcamps to)", "The free Community editions of IntelliJ IDEA and PyCharm, which do not depend on the bootcamp program" ], "detect": [], "source": { "url": "https://blog.jetbrains.com/education/2026/08/31/sunsetting-of-the-jetbrains-teacher-pack-for-bootcamps/", "label": "JetBrains Education blog — blog.jetbrains.com (official)" }, "updated": "2026-09-01" }, { "id": "exchange-web-services-exchange-online-retirement", "url": "https://lastcall.dev/entries/exchange-web-services-exchange-online-retirement", "title": "Microsoft retires Exchange Web Services (EWS) in Exchange Online — blocks requests on October 1, 2026", "vendor": "Microsoft", "what": "Microsoft begins blocking Exchange Web Services (EWS) requests from non-Microsoft apps to Exchange Online; developers must migrate to Microsoft Graph", "category": "API", "sunsetDate": "2026-10-01", "status": "confirmed", "impact": "If your app calls Exchange Web Services (EWS) against Exchange Online or Microsoft 365 mailboxes, Microsoft will start blocking those requests on 1 October 2026. This hits any non-Microsoft app using the EWS Managed API or the EWS SDKs for .NET and Java to read mail, calendars, contacts, or folders in Exchange Online — a common pattern in backup tools, migration utilities, signature managers, CRM connectors, and in-house line-of-business integrations. The block is scoped: it applies only to Microsoft 365 and Exchange Online (all environments). EWS on Exchange Server on-premises is not affected and stays fully supported, so on-prem-only integrations do not need to move.", "migration": "Microsoft's direction is to move Exchange Online access to Microsoft Graph, which it has recommended since it froze EWS feature work in 2018. Inventory every app and script that calls EWS against Exchange Online, then re-implement those calls against the equivalent Microsoft Graph endpoints and permissions. Microsoft acknowledges specific feature gaps that still lack a Graph equivalent — notably access to archive mailboxes and folder-associated information / user configuration — and says it will publish updated timelines for them; if your workload depends on one of those, confirm Graph coverage before committing to a cutover date. Because EWS keeps working until 1 October 2026, migrate and validate app-by-app rather than in a single switchover.", "alternatives": [ "Microsoft Graph — Microsoft's recommended API for programmatic access to Exchange Online mail, calendar, contacts, and folders" ], "detect": [], "source": { "url": "https://techcommunity.microsoft.com/blog/exchange/retirement-of-exchange-web-services-in-exchange-online/3924440", "label": "Retirement of Exchange Web Services in Exchange Online — Microsoft Exchange Team Blog" }, "updated": "2026-08-17" }, { "id": "microsoft-publisher-eol", "url": "https://lastcall.dev/entries/microsoft-publisher-eol", "title": "Microsoft Publisher end of life — 365 subscribers lose it 1 October 2026; convert your .pub files first", "vendor": "Microsoft", "what": "Microsoft Publisher is being discontinued. Microsoft 365 subscribers will not be able to access Publisher after 1 October 2026, and it will no longer be included in Microsoft 365 or available to install or download. The perpetual (one-time-purchase) version reaches end of support on 13 October 2026 with Office LTSC 2021 and consumer Office 2021. Microsoft's recommendation is to convert existing Publisher (.pub) files to PDF or Word before the cutoff.", "category": "Other", "sunsetDate": "2026-10-01", "status": "confirmed", "impact": "Microsoft Publisher is the desktop desktop-publishing app that has shipped in Office for decades, used for newsletters, flyers, brochures, cards, and simple layouts that Word doesn't handle cleanly. Microsoft is retiring it. On its official support page Microsoft states: \"Microsoft 365 subscribers will not be able to access Publisher after October 1, 2026,\" after which \"it will no longer be included in Microsoft 365\" and \"will no longer be available for installation or download.\" For 365 users this is a hard removal, not just an end of updates: \"you will no longer be able to open or edit your Publisher files using Microsoft Publisher.\" The perpetual, one-time-purchase version has a softer landing — its support ends slightly later, on 13 October 2026, alongside Office LTSC 2021 and consumer Office 2021, and Microsoft says perpetual-license holders \"will still be able to access and edit your files\" after that date, just on unsupported software with no security updates, bug fixes, or technical support. The catch that bites people is the file format: .pub is a proprietary format almost nothing else opens, so a folder full of .pub files can become unreadable the moment the only app that opens them is gone. That risk lands on 1 October 2026 for the large majority of users who are on Microsoft 365.", "migration": "Before 1 October 2026, convert every Publisher (.pub) file you want to keep — this is Microsoft's own recommendation (\"Convert your existing files to another format before 10/1/2026\"), and the reason is that no mainstream app reliably opens .pub, so once Publisher is gone the files are effectively stranded. Microsoft points to two target formats: PDF if you only need to view or print the finished layout (open the file in Publisher and save/export as PDF), and Word if you need to keep editing (Microsoft's documented path is to convert the Publisher file to PDF and then open that PDF in Word, since there is no direct .pub-to-.docx export). Do this while Publisher still runs, because after the cutoff a 365 subscriber can no longer open the source files at all. If your work depends on true page-layout control that Word can't match, plan a move to a replacement layout tool (Microsoft suggests Word and Designer for many cases; Canva, Adobe InDesign or Express, Affinity Publisher, or Scribus are the usual step-ups) and rebuild the templates you rely on there before you lose the originals. Perpetual-license holders have a little more runway — the app keeps working after 13 October 2026 — but on unsupported software, so treat conversion as the safe path regardless of license.", "alternatives": [ "Microsoft Word (and Microsoft Designer) — Microsoft's own suggested replacements for much of what Publisher did; convert .pub to PDF, then open in Word to keep editing", "PDF — the format to convert finished layouts to if you only need to view, share, or print them after Publisher is gone", "A dedicated layout tool where you need real page control — Canva, Adobe InDesign or Adobe Express, Affinity Publisher, or the free/open-source Scribus" ], "detect": [], "source": { "url": "https://support.microsoft.com/en-us/publisher/microsoft-publisher-will-no-longer-be-supported-after-october-2026", "label": "Microsoft Publisher will no longer be supported after October 2026 — Microsoft Support (official)" }, "updated": "2026-08-28" }, { "id": "gemini-2-5-models-eol", "url": "https://lastcall.dev/entries/gemini-2-5-models-eol", "title": "Google Gemini 2.5 models deprecated in the Gemini API — only Gemini 2.5 Flash Image now has a shutdown date", "vendor": "Google", "what": "Google has deprecated its Gemini 2.5 models in the Gemini API and directs developers to Gemini 3.x replacements; as of the latest deprecations page only Gemini 2.5 Flash Image carries a shutdown date (2 October 2026), while 2.5 Pro, 2.5 Flash and 2.5 Flash-Lite are listed as deprecated with \"No shutdown date announced\"", "category": "API", "sunsetDate": "2026-10-02", "status": "confirmed", "impact": "Google's official Gemini API deprecations page lists the whole Gemini 2.5 generation as deprecated and points each model at a Gemini 3.x successor. But only one of them now carries a firm shutdown date: Gemini 2.5 Flash Image (gemini-2.5-flash-image) is scheduled to stop being served on 2 October 2026, with gemini-3.1-flash-image-preview named as its replacement. The three text/multimodal models — gemini-2.5-pro, gemini-2.5-flash and gemini-2.5-flash-lite — are marked deprecated but their shutdown-date column now reads \"No shutdown date announced.\" That is a change from earlier in 2026, when the page listed those three with a 16 October 2026 shutdown; Google has since removed that date rather than moved it, so the text models keep answering for now with no published end date. The practical read: if you call gemini-2.5-flash-image, you have a hard deadline of 2 October 2026; if you call the 2.5 text models, you are on a deprecated line with no announced cutoff — safe today, but flagged for migration whenever Google chooses to set a date.", "migration": "For gemini-2.5-flash-image, repoint image-generation calls to gemini-3.1-flash-image-preview before 2 October 2026 and validate output before the cutover — the successor still carries a \"preview\" label, so its behaviour can shift. For the deprecated text models (gemini-2.5-pro, gemini-2.5-flash, gemini-2.5-flash-lite), there is no forced date yet, but \"deprecated\" is Google's signal to plan the move: the named successors are gemini-3.1-pro-preview, gemini-3.6-flash and gemini-3.1-flash-lite respectively. Because these are different model generations, do not assume drop-in parity — output style, context limits, tool-use behaviour, latency and pricing all move between versions. Treat the deprecation as a prompt to test the 3.x models against your prompts now, so that whenever Google does announce a shutdown date for the text models you are already off them. Check the official deprecations page for the current dates rather than relying on a figure quoted elsewhere; Google has already changed this table once.", "alternatives": [ "gemini-3.1-flash-image-preview (Google's named replacement for Gemini 2.5 Flash Image — the one model with a firm 2 Oct 2026 shutdown)", "gemini-3.1-pro-preview (named replacement for the deprecated Gemini 2.5 Pro)", "gemini-3.6-flash (named replacement for the deprecated Gemini 2.5 Flash)", "gemini-3.1-flash-lite (named replacement for the deprecated Gemini 2.5 Flash-Lite)" ], "detect": [ "text:gemini-2.5-flash-image" ], "source": { "url": "https://ai.google.dev/gemini-api/docs/deprecations", "label": "Gemini deprecations — Google AI for Developers (official)" }, "updated": "2026-09-16" }, { "id": "github-copilot-model-deprecations-october-2026", "url": "https://lastcall.dev/entries/github-copilot-model-deprecations-october-2026", "title": "GitHub Copilot deprecates Gemini 3.5 Flash, Gemini 3.6 Flash, Kimi K2.7 Code, and Claude Opus 4.7 on 2 October 2026", "vendor": "GitHub", "what": "GitHub deprecates four selectable Copilot models — Gemini 3.5 Flash, Gemini 3.6 Flash, Kimi K2.7 Code, and Claude Opus 4.7 — across all Copilot experiences on 2 October 2026, directing users to newer replacements", "category": "Feature", "sunsetDate": "2026-10-02", "status": "confirmed", "impact": "GitHub is deprecating four models that today appear in the GitHub Copilot model selector — **Gemini 3.5 Flash**, **Gemini 3.6 Flash**, **Kimi K2.7 Code**, and **Claude Opus 4.7** — on **2 October 2026**, across every Copilot surface: Copilot Chat, inline edits, ask and agent modes, and code completions. For most individual developers this is a light change: GitHub says no action is required to remove the models once deprecated, and picking a model from the Copilot menu simply means choosing a supported one instead. The people who need to act are those who have written one of these model names down somewhere — a script or integration that selects a Copilot model by identifier through the Copilot API, a CI step pinned to a specific model, or a Copilot Enterprise / Copilot Business policy that allow-lists particular models. After 2 October those references no longer resolve to a live model, so requests that name a deprecated model fail or fall back rather than run on the intended model. Enterprise and Business administrators have an extra step: the suggested replacements may need to be enabled through model policies in Copilot settings before users can pick them.", "migration": "Before 2 October 2026, move each deprecated model to its GitHub-suggested replacement: Gemini 3.5 Flash and Gemini 3.6 Flash both to **Gemini 3.8 Flash**, Kimi K2.7 Code to **Kimi K3**, and Claude Opus 4.7 to **Claude Opus 5**. Update any workflow, integration, script, or configuration that names one of the retiring models by identifier. Copilot Enterprise and Copilot Business administrators should enable the replacement models through their model policies in Copilot settings and confirm each shows up in the Copilot Chat model selector, so users can actually pick it. Individuals who just choose a model from the Copilot menu need do nothing — the old option is removed and the replacement is available in its place. Enterprise customers with specific concerns are directed to their GitHub account team.", "alternatives": [ "Gemini 3.8 Flash — GitHub's suggested replacement for both Gemini 3.5 Flash and Gemini 3.6 Flash", "Kimi K3 — GitHub's suggested replacement for Kimi K2.7 Code", "Claude Opus 5 — GitHub's suggested replacement for Claude Opus 4.7" ], "detect": [], "source": { "url": "https://github.blog/changelog/2026-09-03-upcoming-deprecation-of-selected-github-copilot-models", "label": "Upcoming deprecation of selected GitHub Copilot models — GitHub Changelog (official announcement)" }, "updated": "2026-09-04" }, { "id": "cloudflare-zero-trust-route-endpoints-eol", "url": "https://lastcall.dev/entries/cloudflare-zero-trust-route-endpoints-eol", "title": "Cloudflare deprecates CIDR-encoded Zero Trust route endpoints and the Tunnel connections field — end-of-life 5 October 2026", "vendor": "Cloudflare", "what": "Two related Cloudflare Zero Trust / Tunnel API changes reach end-of-life on 5 October 2026: the CIDR-encoded route endpoints (/accounts/{account_id}/teamnet/routes/network/{ip_network_encoded}) are removed in favor of the route_id-based /teamnet/routes endpoints, and the connections array is removed from cfd_tunnel and warp_connector list/get responses", "category": "API", "sunsetDate": "2026-10-05", "status": "confirmed", "impact": "This affects code that manages Cloudflare Zero Trust private network routes or reads Cloudflare Tunnel / Cloudflare Mesh connection state through the API. Cloudflare's deprecations page lists both changes as deprecated on 9 July 2026 with an end-of-life date of 5 October 2026. First, the CIDR-encoded route endpoints — POST/PATCH/DELETE on /accounts/{account_id}/teamnet/routes/network/{ip_network_encoded} — are deprecated in favor of the standard route_id-based endpoints that already exist today (POST /accounts/{account_id}/teamnet/routes, and PATCH/DELETE /accounts/{account_id}/teamnet/routes/{route_id}). Second, the connections array is removed from the list and get responses for Cloudflare Tunnel and Cloudflare Mesh nodes (the cfd_tunnel and warp_connector resources); code must query the dedicated connections endpoint instead of reading the field off the tunnel or node object. The practical risk is unattended automation: Terraform providers, provisioning scripts, and monitoring that address routes by CIDR or parse connections off the tunnel object will start failing after 5 October 2026.", "migration": "Move any route management that targets /accounts/{account_id}/teamnet/routes/network/{ip_network_encoded} (POST, PATCH, or DELETE) to the route_id-based endpoints: POST /accounts/{account_id}/teamnet/routes to create, and PATCH or DELETE /accounts/{account_id}/teamnet/routes/{route_id} to update or remove. Where code currently keys routes by their CIDR block, capture and store the route_id returned on creation and use it thereafter. Separately, stop reading the connections array off cfd_tunnel or warp_connector list/get responses; call the dedicated connections endpoint to enumerate a tunnel's or node's active connections. Update generated clients, vendored wrappers, Terraform, and any CI or monitoring that touches these paths, and re-test before 5 October 2026.", "alternatives": [ "The route_id-based endpoints POST /accounts/{account_id}/teamnet/routes and PATCH/DELETE /accounts/{account_id}/teamnet/routes/{route_id} — Cloudflare's named replacement for the CIDR-encoded route endpoints", "The dedicated Cloudflare Tunnel connections endpoint, in place of reading the connections array off the tunnel or node object" ], "detect": [ "text:teamnet/routes/network" ], "source": { "url": "https://developers.cloudflare.com/fundamentals/api/reference/deprecations/", "label": "Cloudflare API deprecations — developers.cloudflare.com (official)" }, "updated": "2026-09-01" }, { "id": "windows-11-24h2-end-of-servicing", "url": "https://lastcall.dev/entries/windows-11-24h2-end-of-servicing", "title": "Windows 11 version 24H2 end of servicing (Home and Pro)", "vendor": "Microsoft", "what": "Windows 11 24H2 stops receiving updates on Home, Pro, Pro Education and Pro for Workstations", "category": "OS", "sunsetDate": "2026-10-13", "status": "confirmed", "impact": "After this date, Home and Pro machines still running 24H2 receive no further monthly updates, security ones included. The machine keeps working; it simply stops being patched. Enterprise, Education and IoT Enterprise editions of 24H2 are serviced a year longer, to 12 October 2027, and Windows 11 Enterprise LTSC 2024 is unaffected until 2029.", "migration": "Update to version 25H2, which is delivered as an enablement package on 24H2 devices rather than a full feature update — a restart, not a reinstall. Fleets that defer feature updates through Windows Update for Business or WSUS should check that their deferral policy will not hold devices on 24H2 past October.", "alternatives": [ "Windows 11 version 25H2", "Windows 11 Enterprise/Education 24H2 (serviced to 2027-10-12)" ], "detect": [], "source": { "url": "https://learn.microsoft.com/en-us/windows/release-health/windows11-release-information", "label": "Windows 11 release information — Microsoft Learn" }, "updated": "2026-07-21" }, { "id": "cloudflare-workers-kv-legacy-api-eol", "url": "https://lastcall.dev/entries/cloudflare-workers-kv-legacy-api-eol", "title": "Cloudflare retires the legacy Workers KV namespace API routes", "vendor": "Cloudflare", "what": "The old /workers/namespaces/ REST API paths for managing Workers KV stop working; calls must move to the /storage/kv/namespaces/ paths", "category": "API", "sunsetDate": "2026-10-15", "status": "confirmed", "impact": "This affects anything that manages Cloudflare Workers KV namespaces through Cloudflare's REST API on the older URL — CI/CD scripts, infrastructure-as-code, deployment tooling, and any custom automation that calls the /accounts/{account_id}/workers/namespaces/* endpoints. Per Cloudflare's own deprecations page, after 15 October 2026 requests to those legacy routes will no longer be supported. Interactive use through the dashboard and Wrangler is not what this is about; the sharp edge is automation that hardcodes the old path and will start failing once the routes are gone. The good news is that this is a path rename, not a behaviour change: Cloudflare states the legacy and replacement routes are interchangeable — same request parameters, same response payloads — so nothing about how you call the API changes except the URL.", "migration": "Update the base path in any code that hits the KV namespace API: change /accounts/{account_id}/workers/namespaces/ to /accounts/{account_id}/storage/kv/namespaces/. Because Cloudflare says the two route sets accept the same parameters and return the same payloads, this is a find-and-replace on the URL prefix rather than a rewrite — but do it before 15 October 2026, and check generated clients, SDK versions, and any vendored API wrappers that may still target the old path. This is one of several endpoint end-of-life dates Cloudflare has scheduled on the same page; a related one worth noting if you use Cloudflare-managed DNS is the Foundation DNS boolean setting, which the DNS settings API stops returning or accepting beginning 23 November 2026.", "alternatives": [ "The replacement Workers KV routes at /accounts/{account_id}/storage/kv/namespaces/ (same parameters and responses)", "Manage KV via the Cloudflare dashboard or the Wrangler CLI, which are unaffected by this API path change" ], "detect": [ "text:/workers/namespaces/" ], "source": { "url": "https://developers.cloudflare.com/fundamentals/api/reference/deprecations/", "label": "Cloudflare API deprecations — developers.cloudflare.com (official)" }, "updated": "2026-08-16" }, { "id": "minimus-shutdown", "url": "https://lastcall.dev/entries/minimus-shutdown", "title": "Minimus shuts down its hardened container image registry", "vendor": "Minimus", "what": "Minimus, the hardened minimal container image provider, is ending operations: its registry (reg.mini.dev) is turned off on 22 October 2026 after a 60-day maintenance period, and no further updated images will be published", "category": "SaaS", "sunsetDate": "2026-10-22", "status": "confirmed", "impact": "Minimus sells hardened, minimal container images — stripped-down, near-zero-CVE drop-in replacements for standard base and application images (a competitor to Chainguard Images and Docker Hardened Images) — pulled from its registry at reg.mini.dev. In an official notice on minimus.io, the founders say the current business and investment climate has left the company unable to continue operations. The wind-down has two dates that matter to anyone pulling these images in their builds. Beginning Monday 24 August 2026 Minimus enters a 60-day maintenance period: it keeps making bug fixes, provides commercial support, and continues maintaining images with upstream updates. On Thursday 22 October 2026 it ceases operations and turns off the registry. Images already pulled before 22 October keep working, but no new or updated (patched) images are published after that, so anything you pin to reg.mini.dev stops receiving the security updates that were the entire reason to use a hardened image. Enterprise Edition customers will be contacted individually starting 24 August about structured termination of their agreements, including refunds for the remaining contract period beyond 22 October.", "migration": "Treat this as a base-image migration with a hard security deadline: after 22 October 2026 your Minimus images are frozen and will accumulate unpatched CVEs. Inventory every Dockerfile, compose file, and build pipeline that pulls from reg.mini.dev, then repoint each to another hardened/minimal image source and rebuild and test before the cutoff. The closest like-for-like replacements are Chainguard Images and Docker Hardened Images; Google's distroless images cover many runtime bases for free. If you would rather not depend on a single vendor again, you can build your own minimal images from Wolfi/apko or from official -slim / distroless bases. Whatever you choose, re-verify that your application still builds and runs on the new base (users, shells, package managers and CA certs often differ between hardened images) and update any image-scanning baselines. Enterprise customers should also confirm refund and support terms in the individual outreach Minimus says begins 24 August.", "alternatives": [ "Chainguard Images — hardened, low-CVE container images (chainguard.dev)", "Docker Hardened Images (DHI) — Docker's hardened, minimal image line", "Google distroless base images (github.com/GoogleContainerTools/distroless) — free, minimal runtime bases", "Build your own minimal images from Wolfi/apko, or from official -slim / distroless bases" ], "detect": [], "source": { "url": "https://www.minimus.io/", "label": "Minimus is ending operations — Minimus (official wind-down notice on minimus.io, from founders Ben, Dima, and John)" }, "updated": "2026-08-24" }, { "id": "openai-gpt-4-gpt-35-o1-o3-models-eol", "url": "https://lastcall.dev/entries/openai-gpt-4-gpt-35-o1-o3-models-eol", "title": "OpenAI removes GPT-4, GPT-3.5 Turbo, GPT-4 Turbo, o1, o3-mini and o4-mini from the API on 23 October 2026", "vendor": "OpenAI", "what": "OpenAI is removing a large batch of older chat and reasoning models from the API on 23 October 2026 — including gpt-4 (gpt-4-0613), gpt-3.5-turbo, gpt-4-turbo, gpt-4.1-nano, the gpt-4o-2024-05-13 snapshot, o1, o1-pro, o3-mini and o4-mini — directing developers to the gpt-5.6 family", "category": "API", "sunsetDate": "2026-10-23", "status": "confirmed", "impact": "On 23 October 2026 a request that names any of these models by id stops working. OpenAI's [deprecations page](https://developers.openai.com/api/docs/deprecations) lists them with a single shutdown date of **23 October 2026**: **gpt-3.5-turbo** (`gpt-3.5-turbo-0125`), **gpt-4** (`gpt-4-0613`), **gpt-4-1106-preview**, **gpt-4-turbo** (`gpt-4-turbo-2024-04-09`), **gpt-4.1-nano** (`gpt-4.1-nano-2025-04-14`), the **gpt-4o-2024-05-13** snapshot of gpt-4o, **gpt-image-1**, **o1** (`o1-2024-12-17`), **o1-pro**, **o3-mini** and **o4-mini** — plus fine-tuned models built on gpt-3.5-turbo, gpt-4, gpt-4.1-nano, babbage-002 and davinci-002. Any code, library default, notebook, prompt-eval harness, CI step, or config that hardcodes one of these model ids by string will get an error instead of a completion after the date. This bites hardest where a model is pinned deep in an integration and forgotten — a wrapper class, an environment variable, a batch job — rather than in the code path you actively edit. Note the versioning: the general **gpt-4o**, **gpt-4.1** and **gpt-4.5** models are not on this list, only the specific ids above; the retiring **gpt-4.1-nano** is the nano tier, not gpt-4.1 itself, and only the dated **gpt-4o-2024-05-13** snapshot goes, not gpt-4o. This is one wave of a longer rolling schedule — OpenAI's page also removes the GPT-5 dated snapshots, o3 and o3-pro on 11 December 2026, and older audio/realtime and transcription models into 2027.", "migration": "Before 23 October 2026, search your codebase and configuration for the retiring model ids and repoint them. OpenAI's named replacements are the **gpt-5.6** family — `gpt-5.6-sol`, `gpt-5.6-terra` and `gpt-5.6-luna` — with the specific mapping listed per-model on the deprecations page; reasoning workloads on o1/o1-pro/o3-mini/o4-mini move to gpt-5.6 with the appropriate reasoning setting. Grep for the literal ids (`gpt-4`, `gpt-3.5-turbo`, `gpt-4-turbo`, `o1`, `o3-mini`, `o4-mini`) across source, env files, and any prompt/eval configs — not just your main application code. If you maintain **fine-tuned** models on gpt-3.5-turbo, gpt-4, gpt-4.1-nano, babbage-002 or davinci-002, plan to re-tune on a supported base model, since the fine-tunes retire with their base. Because a swapped model can change output shape and cost, treat this as a change to test, not a find-and-replace: re-run your evals against the replacement before the date rather than discovering the difference in production on 23 October.", "alternatives": [ "gpt-5.6-sol / gpt-5.6-terra / gpt-5.6-luna — OpenAI's named replacement family; check the deprecations page for the exact per-model mapping", "For reasoning models (o1, o1-pro, o3-mini, o4-mini): the gpt-5.6 family with the appropriate reasoning mode" ], "detect": [ "text:gpt-3.5-turbo", "text:gpt-4-0613", "text:gpt-4-1106-preview", "text:gpt-4-turbo", "text:gpt-4.1-nano", "text:gpt-4o-2024-05-13", "text:o1-pro", "text:o3-mini", "text:o4-mini" ], "source": { "url": "https://developers.openai.com/api/docs/deprecations", "label": "Deprecations — OpenAI API documentation (official deprecation schedule)" }, "updated": "2026-09-05" }, { "id": "azure-databricks-runtime-10-4-lts-eol", "url": "https://lastcall.dev/entries/azure-databricks-runtime-10-4-lts-eol", "title": "Azure Databricks Runtime 10.4 LTS reaches end of life on 1 November 2026", "vendor": "Microsoft Azure", "what": "Azure Databricks Runtime 10.4 LTS reaches end of life; clusters and jobs must move to a supported Databricks Runtime version", "category": "Runtime", "sunsetDate": "2026-11-01", "status": "confirmed", "impact": "If your Azure Databricks clusters or jobs still run on Databricks Runtime 10.4 LTS, they stop on 1 November 2026. Microsoft says that after this date Databricks Runtime 10.4 LTS \"will no longer be available or usable, and workloads remaining on this version will no longer run\" — so any pipeline, scheduled job, or interactive cluster pinned to 10.4 LTS fails to start once the date passes. This is a hard end of life, not just a support cut-off: the runtime already reached end of support on 18 March 2025, and end of life removes it entirely. Anything left on 10.4 LTS is a broken job waiting to happen.", "migration": "Before 1 November 2026, migrate affected clusters and jobs to a supported Databricks Runtime version. Inventory every cluster policy, job definition, and Databricks Asset Bundle whose Spark/runtime version is pinned to 10.4 LTS, re-target each to a current supported LTS runtime, and test — a jump this large (10.4 dates to 2022) can bring Spark and library behaviour changes, so validate each workload on the new runtime before cutting production over. Because 10.4 LTS keeps running until the date, you can migrate and validate job-by-job rather than all at once.", "alternatives": [ "A current supported Databricks Runtime LTS version — newer long-term-support runtimes still receiving updates (per Databricks' runtime support lifecycle)" ], "detect": [], "source": { "url": "https://azure.microsoft.com/updates?id=569353", "label": "Announcing: Azure Databricks Runtime 10.4 LTS will reach end of life on November 1, 2026 — Azure Updates (id 569353)" }, "updated": "2026-08-15" }, { "id": "alpine-3-21-end-of-life", "url": "https://lastcall.dev/entries/alpine-3-21-end-of-life", "title": "Alpine Linux 3.21 reaches end of life on November 1, 2026", "vendor": "Alpine Linux", "what": "The Alpine Linux 3.21 release branch reaches end of support (end of life) on November 1, 2026. After that date the 3.21 branch stops receiving security fixes and package updates, so container images built on the `alpine:3.21` base tag no longer get patched.", "category": "OS", "sunsetDate": "2026-11-01", "status": "confirmed", "impact": "Alpine Linux is the minimal distribution that underpins a huge share of the world's container images — it is one of the most common `FROM` base images in Dockerfiles because of its tiny size. Alpine supports each stable release branch for about two years; per its official releases table, the 3.21 branch (released December 5, 2024) reaches end of support on November 1, 2026. Once a branch is end-of-life, Alpine no longer publishes security fixes or package updates for it. In practice that means any image built on `alpine:3.21` (or the point releases under it, like `alpine:3.21.7`) will stop receiving CVE patches after that date, so containers pinned to that tag quietly accumulate unfixed vulnerabilities in the base OS and its `apk` packages even though they keep running. This affects application images, CI base images, and any Dockerfile or compose file that pins the `3.21` tag rather than a still-supported branch. It does not affect newer Alpine branches (3.22, 3.23) or the rolling `edge` branch, which remain supported on their own schedules.", "migration": "Move container images off the `alpine:3.21` base tag to a supported Alpine release branch before November 1, 2026. Inventory your Dockerfiles, compose files, and CI configs for `FROM alpine:3.21` (and any `alpine:3.21.x` point-release pins), then bump them to a current supported branch such as `alpine:3.22` or `alpine:3.23`, or to `alpine:latest` if you track the newest stable. Rebuild and test images against the new base — Alpine minor upgrades occasionally change package versions (musl, busybox, and `apk` packages), so verify that your runtime dependencies and any compiled artifacts still work. If you cannot upgrade the branch immediately, at minimum plan the move soon: an EOL base image is a security-patch dead end, not a stable long-term pin. Teams that need a longer, vendor-backed support window on a container base OS may prefer a distribution with a longer LTS commitment.", "alternatives": [ "Alpine Linux 3.22 or 3.23 — current supported Alpine stable branches, each with its own ~2-year support window", "A distribution with a longer support commitment as a container base (e.g. Debian stable, Ubuntu LTS) where a longer patch window matters more than image size", "Distroless or Wolfi/Chainguard base images — minimal, actively-maintained alternatives for size-sensitive containers" ], "detect": [ "image:alpine:3.21" ], "source": { "url": "https://alpinelinux.org/releases/", "label": "Alpine Linux Releases — alpinelinux.org (official release/end-of-support table)" }, "updated": "2026-09-12" }, { "id": "mullvad-public-encrypted-dns-shutdown", "url": "https://lastcall.dev/entries/mullvad-public-encrypted-dns-shutdown", "title": "Mullvad shuts down its public encrypted DNS (DoH) servers — migrate to Quad9 before 2 November 2026", "vendor": "Mullvad", "what": "Mullvad is shutting down its public encrypted DNS (DoH) servers at dns.mullvad.net and recommending Quad9 instead; anyone who manually configured a Mullvad DoH resolver must switch before 2 November 2026 or lose DNS resolution", "category": "SaaS", "sunsetDate": "2026-11-02", "status": "confirmed", "impact": "Mullvad has run free public encrypted DNS (DNS-over-HTTPS) servers since 2022 — the resolvers at `dns.mullvad.net` and its variants (base, extended, family, adblock) that anyone could point a device or browser at to keep their ISP from seeing the domains they visit. Mullvad is shutting that public service down and financially supporting the Quad9 Foundation instead, on the reasoning that running a privacy-focused public resolver is a specialized job Quad9 already does well. The date to plan against: **if you have manually configured a Mullvad DoH server, switch before 2 November 2026.** This does not affect people using the Mullvad VPN app, whose DNS is handled internally by the VPN and never used these public servers. It affects three groups: anyone who hardcoded a Mullvad DoH endpoint into a device, router, browser, or systemd-resolved / DoH-client config; Mullvad Browser users who customized their DoH away from the default; and iOS/macOS users who installed a Mullvad DoH configuration profile — those profiles will stop working. Mullvad Browser users on the default DoH (or the default ad-blocking one) are migrated to Quad9 automatically and need do nothing.", "migration": "If you manually configured any Mullvad DoH resolver (`dns.mullvad.net`, `base.dns.mullvad.net`, `extended.dns.mullvad.net`, `family.dns.mullvad.net`, `adblock.dns.mullvad.net`, or similar), replace it with a Quad9 endpoint before 2 November 2026 — Mullvad points to Quad9's own setup guides. On iOS and macOS, remove the existing Mullvad DoH configuration profile and install the equivalent Quad9 profile. In Mullvad Browser, if you customized the DoH setting, change it back to the default so you are migrated to Quad9 automatically; if you kept the default (or the default ad-blocking option), no action is needed. Mullvad VPN app users are unaffected — the app's internal DNS handles queries and does not depend on the public servers.", "alternatives": [ "Quad9 (9.9.9.9 / dns.quad9.net) — the privacy-focused public resolver Mullvad now recommends and financially supports, with its own DoH/DoT setup guides for browsers, iOS, and macOS" ], "detect": [ "text:dns.mullvad.net" ], "source": { "url": "https://mullvad.net/en/blog/shutting-down-our-public-encrypted-dns-servers-and-sponsoring-quad9-instead", "label": "Shutting down our public encrypted DNS servers and sponsoring Quad9 instead — Mullvad blog (official announcement)" }, "updated": "2026-09-04" }, { "id": "dotnet-8-and-9-end-of-support", "url": "https://lastcall.dev/entries/dotnet-8-and-9-end-of-support", "title": ".NET 8 and .NET 9 reach end of support on 10 November 2026", "vendor": "Microsoft", "what": "Microsoft ends support for .NET 8 (LTS) and .NET 9 (STS) — after 10 November 2026 neither receives security patches, bug fixes, or technical support", "category": "Runtime", "sunsetDate": "2026-11-10", "status": "confirmed", "impact": "Microsoft's official .NET support policy lists both .NET 8 and .NET 9 with an end-of-support date of 10 November 2026. .NET 8 is a Long Term Support (LTS) release; .NET 9 is a Standard Term Support (STS) release; they share the same end date. After that date, Microsoft stops shipping security updates, bug fixes, and technical support for both — apps keep running, but any newly discovered vulnerability in the runtime or framework libraries goes unpatched. This affects the very large base of production services, container images, and libraries still targeting `net8.0` or `net9.0`, plus CI images pinned to `mcr.microsoft.com/dotnet/*:8.0` or `:9.0`. It matters most where an unpatched runtime is a compliance or security problem: internet-facing ASP.NET Core apps, anything handling regulated data, and base images baked into other people's builds. The supported successor is .NET 10 (LTS), which Microsoft supports through 14 November 2028.", "migration": "Before 10 November 2026, retarget applications from `net8.0` / `net9.0` to `net10.0`, update NuGet package references to their .NET 10-compatible versions, and rebuild. In Dockerfiles and CI, bump base images from `mcr.microsoft.com/dotnet/aspnet:8.0`, `sdk:8.0`, or `runtime:8.0` (and the `9.0` equivalents) to the `10.0` tags. .NET 10 is an LTS release, so moving there — rather than to another STS — buys the longest runway (support through 14 November 2028). Teams that cannot move in time should at minimum inventory which services still run on 8.0/9.0 and treat any post-date CVE in those runtimes as unpatchable until they migrate.", "alternatives": [ ".NET 10 (LTS) — supported through 14 November 2028, the direct upgrade target" ], "detect": [ "text:net8.0", "text:net9.0", "image:mcr.microsoft.com/dotnet/aspnet:8.0", "image:mcr.microsoft.com/dotnet/sdk:8.0", "image:mcr.microsoft.com/dotnet/runtime:8.0", "image:mcr.microsoft.com/dotnet/aspnet:9.0", "image:mcr.microsoft.com/dotnet/sdk:9.0", "image:mcr.microsoft.com/dotnet/runtime:9.0" ], "source": { "url": "https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core", "label": ".NET and .NET Core Support Policy — dotnet.microsoft.com (official lifecycle table)" }, "updated": "2026-09-02" }, { "id": "postgresql-14-end-of-life", "url": "https://lastcall.dev/entries/postgresql-14-end-of-life", "title": "PostgreSQL 14 reaches end of life on 12 November 2026", "vendor": "PostgreSQL Global Development Group", "what": "PostgreSQL 14 reaches end of life — after 12 November 2026 the community ships no further bug fixes or security patches for the 14.x line", "category": "Runtime", "sunsetDate": "2026-11-12", "status": "confirmed", "impact": "The PostgreSQL project supports each major version for five years, and its official versioning policy lists PostgreSQL 14 (current minor 14.24) with a final release date of 12 November 2026. After that date the community releases no further minor versions for 14.x — no bug fixes and, critically, no security patches. A PostgreSQL 14 server keeps running, but any vulnerability found in the server after that date goes unfixed on 14, so anything internet-reachable or holding regulated data becomes a compliance and security problem the day a relevant CVE lands. This affects a very large installed base: self-managed clusters pinned to 14, containers built `FROM postgres:14`, and CI/test databases that quietly pin the major. Managed providers set their own timelines that usually track the community EOL — AWS RDS, Azure Database for PostgreSQL, Google Cloud SQL and others typically force an upgrade or move you to paid extended support around the same window, so the community date is the one to plan against.", "migration": "Upgrade to a supported major version before 12 November 2026 — PostgreSQL 15 (EOL 11 November 2027), 16 (9 November 2028), 17 (8 November 2029), or 18 (14 November 2030). Moving to 17 or 18 buys the longest runway. Plan a major-version upgrade using `pg_upgrade` (fast, in-place) or logical replication / dump-and-restore for a low-downtime cutover, and test on a copy first — major upgrades can require reindexing and application checks for changed defaults. In Dockerfiles and compose files, bump `postgres:14` base images to a supported tag. If you run managed PostgreSQL, check your provider's specific PostgreSQL 14 retirement date and their extended-support pricing, since forced upgrades and billing changes are usually scheduled around the community EOL.", "alternatives": [ "PostgreSQL 17 — supported through 8 November 2029", "PostgreSQL 18 — supported through 14 November 2030 (longest runway)", "PostgreSQL 15 or 16 — nearer upgrade targets if a smaller version jump is preferred" ], "detect": [ "image:postgres:14" ], "source": { "url": "https://www.postgresql.org/support/versioning/", "label": "PostgreSQL Versioning Policy — postgresql.org (official supported-versions table)" }, "updated": "2026-09-03" }, { "id": "cloudflare-foundation-dns-boolean-eol", "url": "https://lastcall.dev/entries/cloudflare-foundation-dns-boolean-eol", "title": "Cloudflare deprecates the foundation_dns boolean in the DNS settings API — end-of-life 23 November 2026, switch to nameservers.type cloudflare.advanced", "vendor": "Cloudflare", "what": "The foundation_dns boolean in Cloudflare's DNS settings endpoints (/zones/{zone_id}/dns_settings and /accounts/{account_id}/dns_settings) is deprecated; code must select Advanced Nameservers via nameservers.type: \"cloudflare.advanced\" instead", "category": "API", "sunsetDate": "2026-11-23", "status": "confirmed", "impact": "This affects any automation that reads or sets Advanced Nameservers (Cloudflare's Foundation DNS feature) through the API using the foundation_dns boolean. On Cloudflare's deprecations page, that boolean is listed as deprecated on 27 July 2026 with an end-of-life date of 23 November 2026 in the DNS settings endpoints for both zone settings (/zones/{zone_id}/dns_settings) and account defaults (/accounts/{account_id}/dns_settings). The replacement is a different field on the same endpoints: nameservers.type set to \"cloudflare.advanced\". Cloudflare also warns of a transition window — beginning 26 October 2026, the DNS settings API gradually starts representing Advanced Nameservers with nameservers.type: \"cloudflare.advanced\", a rollout it expects to take about seven days per account. The practical risk is unattended: infrastructure-as-code and provisioning scripts that toggle foundation_dns, or that assert on it when reading settings, will drift or break as the representation changes and then as the field reaches end-of-life. Interactive dashboard users are unaffected.", "migration": "Update any code that reads or writes the foundation_dns boolean on /zones/{zone_id}/dns_settings or /accounts/{account_id}/dns_settings to use nameservers.type: \"cloudflare.advanced\" instead, before 23 November 2026. Because Cloudflare begins gradually re-representing Advanced Nameservers with the new field on 26 October 2026 (a rollout of roughly seven days), fix code that asserts on the old boolean before that window rather than at the end-of-life date — otherwise a config-drift check or a Terraform plan can start reporting spurious changes mid-rollout. Update generated clients, vendored wrappers, and any Terraform or CI steps that touch DNS settings, and re-test that reads and writes behave against the new field.", "alternatives": [ "Set nameservers.type: \"cloudflare.advanced\" on the DNS settings endpoints to configure Advanced Nameservers — Cloudflare's named replacement for the foundation_dns boolean", "The Cloudflare dashboard, which is unaffected by this API field deprecation" ], "detect": [ "text:foundation_dns" ], "source": { "url": "https://developers.cloudflare.com/fundamentals/api/reference/deprecations/", "label": "Cloudflare API deprecations — developers.cloudflare.com (official)" }, "updated": "2026-08-31" }, { "id": "openai-gpt-image-models-eol", "url": "https://lastcall.dev/entries/openai-gpt-image-models-eol", "title": "OpenAI removes the older GPT Image models from the API", "vendor": "OpenAI", "what": "OpenAI is deprecating three GPT Image generation models — gpt-image-1-mini, gpt-image-1.5 and chatgpt-image-latest — and removing them from the API, directing developers to gpt-image-2", "category": "API", "sunsetDate": "2026-12-01", "status": "confirmed", "impact": "On 2 June 2026 OpenAI notified developers that three older GPT Image models — gpt-image-1-mini, gpt-image-1.5 and chatgpt-image-latest — are deprecated and will be removed from the API on 1 December 2026. After that date, calls naming those model identifiers stop being answered. Unlike OpenAI's Sora 2 removal, this one names a direct replacement — gpt-image-2 — so it is a version migration rather than a capability being withdrawn: image generation stays on the platform, only the older model strings go away. The exposure is anything that hard-codes one of the three identifiers: an app that generates or edits images on demand, a pipeline that renders assets from prompts, or code pinned to chatgpt-image-latest — which, despite the \"latest\" in its name, is a fixed alias being retired, not one that will roll forward to the new model on its own. Deprecated models keep working until the date, so nothing breaks the day you read this, but the runway is finite.", "migration": "Move each affected call from gpt-image-1-mini, gpt-image-1.5 or chatgpt-image-latest to gpt-image-2, the replacement OpenAI names for all three. Because a replacement exists on the same platform, this is closer to a model-string swap than the provider change a capability withdrawal would force — but test rather than assume drop-in parity: image models differ in output characteristics, supported parameters and pricing between versions, so validate the results and cost of gpt-image-2 against what you rely on today before the cutover. Anything pinned to chatgpt-image-latest deserves particular attention: the alias is being removed rather than repointed, so it must be updated explicitly.", "alternatives": [ "gpt-image-2 (the vendor-named replacement for all three models)" ], "detect": [ "text:gpt-image-1-mini", "text:gpt-image-1.5", "text:chatgpt-image-latest" ], "source": { "url": "https://developers.openai.com/api/docs/deprecations", "label": "Deprecations — OpenAI API (official)" }, "updated": "2026-07-31" }, { "id": "cloudflare-dns-analytics-api-eol", "url": "https://lastcall.dev/entries/cloudflare-dns-analytics-api-eol", "title": "Cloudflare retires the REST DNS Analytics API and DNS Firewall Analytics API — end-of-life 1 December 2026, move to the GraphQL Analytics API", "vendor": "Cloudflare", "what": "The REST DNS Analytics API (/zones/{zone_id}/dns_analytics/) and DNS Firewall Analytics API (/accounts/{account_id}/dns_firewall/{id}/dns_analytics/report) stop working; analytics automation must move to Cloudflare's GraphQL Analytics API", "category": "API", "sunsetDate": "2026-12-01", "status": "confirmed", "impact": "This affects anything that pulls DNS query analytics from Cloudflare through the old REST endpoints — dashboards, capacity and traffic reports, anomaly alerting, and any scheduled job that reads DNS or DNS Firewall analytics by calling /zones/{zone_id}/dns_analytics/ or /accounts/{account_id}/dns_firewall/{dns_firewall_id}/dns_analytics/report. On Cloudflare's own deprecations page, both REST APIs are listed as deprecated (announced 9 December 2025) and reaching end-of-life on 1 December 2026, after which requests to them are no longer supported. The analytics themselves are not going away: Cloudflare says all existing functionality is fully supported by its GraphQL Analytics API, which it positions as the higher-performance, longer-term home for this data. As with Cloudflare's other endpoint retirements, the sharp edge is unattended automation rather than interactive use — someone reading graphs in the dashboard notices nothing, but a reporting pipeline that queries the REST path on a schedule will start failing on the date. The move is more than a URL swap: GraphQL uses a different query model, so integrations need to be re-written, not just re-pointed.", "migration": "Migrate any integration that reads DNS or DNS Firewall analytics from the REST endpoints to Cloudflare's GraphQL Analytics API before 1 December 2026. Because GraphQL is a different query shape rather than a drop-in path rename, budget real work: identify the metrics and dimensions your current reports use, express them as GraphQL queries against the DNS analytics datasets, and update the code, credentials, and any scheduled jobs or dashboards that consume the output. Cloudflare links the GraphQL replacements for both the DNS Analytics API and the DNS Firewall Analytics API from the same deprecations page. Do the cut-over before the date so a report does not silently go blank.", "alternatives": [ "Cloudflare's GraphQL Analytics API for DNS analytics (developers.cloudflare.com/analytics/graphql-api/) — the named replacement for both REST endpoints" ], "detect": [ "text:/dns_analytics" ], "source": { "url": "https://developers.cloudflare.com/fundamentals/api/reference/deprecations/", "label": "Cloudflare API deprecations — developers.cloudflare.com (official)" }, "updated": "2026-08-31" }, { "id": "remove-bg-standalone-site-api-shutdown", "url": "https://lastcall.dev/entries/remove-bg-standalone-site-api-shutdown", "title": "remove.bg standalone site and self-service API shut down as background removal moves to Canva", "vendor": "remove.bg (Canva)", "what": "The remove.bg standalone website and its self-service background-removal API stop working; the tool moves into Canva and the API to Leonardo.ai", "category": "SaaS", "sunsetDate": "2026-12-01", "status": "confirmed", "impact": "remove.bg is the widely-used one-click background-removal service and API, owned by Canva since 2021. From 1 December 2026 at 9:00am CET the standalone remove.bg website will no longer be available, and the self-service remove.bg API will stop accepting requests on the same date. If you call `api.remove.bg/v1.0/removebg` from a script, plugin, or app on a self-service (pay-as-you-go / credit) plan, those calls will start failing on 1 December 2026 — and any remaining self-service credits expire then too. Enterprise API customers are the exception: remove.bg states those contracts are not affected and continue as normal.", "migration": "Two different destinations depending on how you use it. For browser-based background removal, the functionality moves into Canva. For the API, remove.bg points developers to Leonardo.ai (also part of Canva), which now offers background removal plus upscaling and scene generation — but it is a different API with a different base URL and auth, so this is a re-integration, not a drop-in host swap. Migrate before 1 December: after that the self-service endpoint stops responding and unused credits are gone. If you only need occasional removals, Canva covers it; if you have an automated pipeline, plan the Leonardo.ai (or alternative) rewrite now rather than discovering the 401/blocked responses in production.", "alternatives": [ "Canva (browser-based background removal)", "Leonardo.ai background-removal API (remove.bg's official API destination)", "Photoroom API", "Cloudinary background removal add-on", "rembg (self-hostable, open source)" ], "detect": [ "text:api.remove.bg" ], "source": { "url": "https://www.remove.bg/faq", "label": "remove.bg FAQ — \"remove.bg is moving to Canva\"" }, "updated": "2026-09-15" }, { "id": "pulley-shutdown", "url": "https://lastcall.dev/entries/pulley-shutdown", "title": "Pulley cap table platform is shutting down — all operations and services cease on 8 December 2026", "vendor": "Pulley", "what": "Pulley, the venture-backed cap table and equity management platform for startups, will shut down and cease all operations and services on 8 December 2026, directing customers to migrate to Carta under an exclusive partnership", "category": "SaaS", "sunsetDate": "2026-12-08", "status": "confirmed", "impact": "Pulley — an equity-management and cap table platform used by startups to track ownership, issue equity, run 409A valuations and manage stakeholder records — is shutting down entirely. A notice on its own homepage states plainly that \"Pulley will be shutting down and will cease all operations and services on 12/8/26.\" This is a full company shutdown, not a feature retirement: after 8 December 2026 the product and its services stop. The company says it has entered an exclusive partnership with Carta so that \"Pre-IPO companies can still access market-leading equity management capabilities,\" and that existing Pulley customers may qualify for a limited-time offer and assisted migration to Carta. The exposure is concentrated and serious: a cap table is the legal record of who owns a company, and equity data, option-grant records, 409A history and stakeholder access all live inside the platform being switched off. Anyone relying on Pulley for equity administration needs to export their records and stand up a replacement before the cutoff, and anyone with API or automated integrations pointed at Pulley needs to retire them. Because this is a hosted SaaS platform rather than a package or image, it leaves no fingerprint a code scanner can catch — the deadline has to be tracked, not detected.", "migration": "Log in to your Pulley account well before 8 December 2026 to check account status and, if eligible, redeem the assisted-migration offer to Carta that Pulley is directing customers toward. Regardless of whether you move to Carta or another equity-management provider, export everything Pulley holds while the platform is still live: the full cap table, security/option ledgers, stakeholder records, 409A valuation reports and any board or compliance documents — a cap table is a legal record and reconstructing it after the service is gone is far harder than exporting it now. If you have automated processes or integrations calling Pulley, plan to repoint or retire them. Do not leave the migration to the final weeks: assisted-migration offers and support capacity typically thin out as a shutdown date approaches.", "alternatives": [ "Carta — Pulley's named migration partner; existing customers may qualify for an assisted-migration offer", "Other equity-management / cap table platforms (e.g. AngelList, Vestd, or a qualified startup attorney's cap table tooling) if Carta is not the right fit" ], "detect": [], "source": { "url": "https://pulley.com", "label": "Pulley shutdown notice — pulley.com (official homepage banner)" }, "updated": "2026-09-16" }, { "id": "azure-linux-os-guard-aks-retirement", "url": "https://lastcall.dev/entries/azure-linux-os-guard-aks-retirement", "title": "Azure Linux with OS Guard in Azure Kubernetes Service (AKS) is retiring on December 10, 2026", "vendor": "Microsoft Azure", "what": "Microsoft is retiring Azure Linux with OS Guard (preview) as a node pool operating system in Azure Kubernetes Service (AKS). Support ends December 10, 2026, after which no new Azure Linux with OS Guard node pools can be created and existing pools stop receiving node images and security patches; on March 10, 2027 AKS removes the node images entirely. Azure Container Linux is the named replacement.", "category": "OS", "sunsetDate": "2026-12-10", "status": "confirmed", "impact": "Azure Linux with OS Guard is a hardened, preview node pool OS option for Azure Kubernetes Service (AKS). Microsoft is winding it down in two steps. Starting December 10, 2026: you will no longer be able to create new Azure Linux with OS Guard (preview) node pools; AKS will stop producing new node images for affected pools; and existing pools will no longer receive security patches — so any cluster still running these node pools becomes progressively less secure the longer it stays on them. Then on March 10, 2027, AKS removes the Azure Linux with OS Guard node images altogether, and after that point any scaling or remediation operation on an affected node pool — including reimage and redeploy — will fail. In practice that means an unmigrated node pool can be left unable to scale up, self-heal, or recover nodes. Because this is a preview OS SKU, the blast radius is teams who opted into Azure Linux with OS Guard specifically (often for its confidential/hardened posture) rather than the default Azure Linux or Ubuntu node pools, which are unaffected by this notice.", "migration": "Microsoft names Azure Container Linux as the replacement and points to a migration tutorial for moving affected node pools. Do it before December 10, 2026 to keep receiving security patches, and well before March 10, 2027 to avoid losing scaling and remediation on the node pools. First, inventory which AKS node pools use Azure Linux with OS Guard (check the node pool OS SKU across your clusters and subscriptions, e.g. via `az aks nodepool list`), since only those pools are affected — default Azure Linux and Ubuntu node pools are not. Then migrate each affected pool to Azure Container Linux following Microsoft's \"Migrate to Azure Container Linux\" tutorial for AKS. Validate workloads on the new OS in a non-production cluster first, especially anything that depended on OS Guard's hardened image characteristics, then roll the change through production node pools before the December cutoff.", "alternatives": [ "Azure Container Linux — Microsoft's named replacement for Azure Linux with OS Guard in AKS (migration tutorial provided)", "Standard Azure Linux node pools in AKS — the general-purpose Azure Linux (Mariner-derived) node OS, unaffected by this retirement", "Ubuntu node pools in AKS — the default node OS option, unaffected" ], "detect": [], "source": { "url": "https://azure.microsoft.com/updates?id=571257", "label": "Azure Updates — \"Retirement: Azure Linux with OS Guard in Azure Kubernetes Service\" (official)" }, "updated": "2026-09-12" }, { "id": "openai-gpt-5-o3-snapshots-removed-december-2026", "url": "https://lastcall.dev/entries/openai-gpt-5-o3-snapshots-removed-december-2026", "title": "OpenAI removes the GPT-5 and o3 snapshots gpt-5-2025-08-07, o3-2025-04-16 and o3-pro-2025-06-10 from the API on 11 December 2026", "vendor": "OpenAI", "what": "OpenAI is removing the dated GPT-5 and o3 model snapshots — gpt-5-2025-08-07, gpt-5-mini-2025-08-07, gpt-5-nano-2025-08-07, gpt-5-pro-2025-10-06, o3-2025-04-16 and o3-pro-2025-06-10 — from the API on 11 December 2026, directing developers to the gpt-5.6 family", "category": "API", "sunsetDate": "2026-12-11", "status": "confirmed", "impact": "On 11 December 2026, a request that pins any of these dated GPT-5 or o3 snapshots by id stops working. OpenAI's [deprecations page](https://developers.openai.com/api/docs/deprecations) records that *\"on June 11, 2026, we notified developers using older GPT-5 and o3 model snapshots of their deprecation and removal from the API on December 11, 2026,\"* and lists six ids against that single shutdown date: **gpt-5-2025-08-07**, **gpt-5-mini-2025-08-07**, **gpt-5-nano-2025-08-07**, **gpt-5-pro-2025-10-06**, **o3-2025-04-16** and **o3-pro-2025-06-10**. The catch is the difference between an alias and a snapshot. If your code calls the unversioned `gpt-5`, `gpt-5-mini`, `gpt-5-nano` or `o3` alias, OpenAI keeps repointing it to a current model and nothing breaks on the date. What breaks is code that pins the *specific dated snapshot* — the exact string `gpt-5-2025-08-07` or `o3-pro-2025-06-10` — which teams do deliberately for reproducibility: eval harnesses, regression suites, cached prompt configs, batch jobs, and anything that hardcodes a snapshot so results do not shift under it. Those requests return an error after 11 December 2026 rather than a completion. This is the same rolling schedule that removes the older GPT-4/GPT-3.5/o1/o3-mini batch on 23 October 2026 and the legacy audio, realtime and transcription models into 2027 — this wave is specifically the current-generation GPT-5 and o3 dated snapshots.", "migration": "Before 11 December 2026, grep your codebase, environment files, notebooks and eval/CI configs for the six exact snapshot ids and repoint them. OpenAI's named per-model replacements are the **gpt-5.6** family: `gpt-5-2025-08-07` → **gpt-5.6-sol**, `gpt-5-mini-2025-08-07` → **gpt-5.6-terra**, `gpt-5-nano-2025-08-07` → **gpt-5.6-luna**, `gpt-5-pro-2025-10-06` → **gpt-5.6-sol** (with `reasoning.mode: pro`), `o3-2025-04-16` → **gpt-5.6-sol**, and `o3-pro-2025-06-10` → **gpt-5.6-sol** (with `reasoning.mode: pro`). Search for the literal dated strings, not the bare `gpt-5`/`o3` aliases — an alias call is already on a supported model, and it is the pinned snapshot that is the exposure. Because a swapped model can change output shape, latency and cost, treat this as a change to test: re-run your evals against the replacement before the date rather than discovering the difference in production on 11 December. If reproducibility is the reason you pinned the snapshot in the first place, re-baseline your golden outputs against the gpt-5.6 replacement as part of the switch.", "alternatives": [ "gpt-5.6-sol — replacement for gpt-5-2025-08-07, gpt-5-pro-2025-10-06 (reasoning.mode: pro), o3-2025-04-16 and o3-pro-2025-06-10 (reasoning.mode: pro)", "gpt-5.6-terra — replacement for gpt-5-mini-2025-08-07", "gpt-5.6-luna — replacement for gpt-5-nano-2025-08-07" ], "detect": [ "text:gpt-5-2025-08-07", "text:gpt-5-mini-2025-08-07", "text:gpt-5-nano-2025-08-07", "text:gpt-5-pro-2025-10-06", "text:o3-2025-04-16", "text:o3-pro-2025-06-10" ], "source": { "url": "https://developers.openai.com/api/docs/deprecations", "label": "Deprecations — OpenAI API documentation (official deprecation schedule)" }, "updated": "2026-09-07" }, { "id": "php-8-2-end-of-life", "url": "https://lastcall.dev/entries/php-8-2-end-of-life", "title": "PHP 8.2 reaches end of life (security support ends) on December 31, 2026", "vendor": "PHP", "what": "PHP 8.2 reaches its security end-of-life on December 31, 2026. Active (bug-fix) support already ended December 31, 2024; after the 2026 date the 8.2 branch receives no further releases at all, including security fixes, so applications and container images pinned to `php:8.2` stop getting patched.", "category": "Runtime", "sunsetDate": "2026-12-31", "status": "confirmed", "impact": "PHP versions get roughly two years of active (bug-fix) support followed by one more year of security-only fixes. Per php.net's official support table, PHP 8.2 was released December 8, 2022, its active support ended December 31, 2024, and its **security support ends December 31, 2026**. After that date the PHP project publishes no further 8.2 releases — not even for critical security vulnerabilities — so anything still running 8.2 accumulates unpatched CVEs while continuing to work. This is one of the most widely deployed PHP branches: it underpins a large share of WordPress, Laravel, Symfony, Drupal and general PHP application deployments, and the official `php:8.2` Docker images (including the common `php:8.2-fpm`, `php:8.2-apache`, and `php:8.2-cli` tags) that back countless container builds. It does not affect PHP 8.3 (security support through December 31, 2027) or 8.4 (through December 31, 2028), which remain supported on their own schedules.", "migration": "Upgrade to a supported PHP release — 8.3 or 8.4 — before December 31, 2026. Most PHP 8.2 code runs on 8.3 and 8.4 with few or no changes; review the official migration guides (`UPGRADING` / \"Migrating from PHP 8.2.x to 8.3.x\" and to 8.4.x) for deprecations and behavior changes, run your test suite against the new runtime, and check that any C-extensions (and PECL modules) you depend on ship builds for the target version. For Dockerized apps, bump the base image from `php:8.2` (and `php:8.2-fpm` / `php:8.2-apache`) to the matching `php:8.3` or `php:8.4` tag and rebuild. If you run PHP through a managed platform (a hosting control panel, a PaaS, or a distro package), confirm that platform offers 8.3/8.4 before the deadline. Staying on 8.2 past its security EOL means running an internet-facing runtime that will never be patched again.", "alternatives": [ "PHP 8.3 — active support through December 31, 2025, security support through December 31, 2027", "PHP 8.4 — the current release; active support through December 31, 2026, security support through December 31, 2028", "A commercial extended-support offering (e.g. a vendor backporting security fixes) only as a stopgap if an upgrade genuinely cannot be completed in time" ], "detect": [ "image:php:8.2" ], "source": { "url": "https://www.php.net/supported-versions.php", "label": "Supported Versions — php.net (official PHP release support table)" }, "updated": "2026-09-13" }, { "id": "standard-notes-listed-shutdown", "url": "https://lastcall.dev/entries/standard-notes-listed-shutdown", "title": "Standard Notes shuts down Listed, its blogging platform", "vendor": "Standard Notes", "what": "Standard Notes is sunsetting Listed, its publishing/blogging platform; the site and all public blogs go offline", "category": "SaaS", "sunsetDate": "2026-12-31", "status": "confirmed", "impact": "Listed is the blogging/publishing platform run by Standard Notes, the privacy-first note-taking app — it let Standard Notes users publish notes as a public blog, with a guestbook and optional custom domains. Standard Notes is retiring it. The announcement states the platform \"will permanently shut down December 31, 2026.\" After that date the Listed website and your blog — past posts and guestbook included — will no longer be publicly accessible. Your underlying content is not deleted: data you published on Listed remains available inside your personal Standard Notes account. What goes away is the public-facing blog and its URLs, so anyone linking to a listed.to page, or relying on it for a public presence, loses that on 31 December 2026.", "migration": "Your writing survives inside Standard Notes, so this is about preserving the public side, not rescuing the text. Before 31 December 2026: export or copy anything you want to keep in a portable form, and save copies of published posts you only have on Listed. If you used a custom domain with Listed, it will stop serving your blog when Listed is retired — repoint that domain's DNS to a new host before the cutoff so links you control keep resolving. To keep publishing publicly, move to another static-blog or writing platform and republish the posts that matter. Standard Notes points questions to help@standardnotes.com.", "alternatives": [ "Bear Blog", "Ghost", "WriteFreely / write.as", "Mataroa", "A static-site generator (Astro, Hugo, Eleventy) on your own domain" ], "detect": [], "source": { "url": "https://listed.to/@Listed/76799/an-update-about-listed", "label": "Listed announcement — \"An update about Listed\"" }, "updated": "2026-09-15" }, { "id": "mariadb-13-0-end-of-life", "url": "https://lastcall.dev/entries/mariadb-13-0-end-of-life", "title": "MariaDB 13.0 reaches end of life on 31 December 2026 — a short-term rolling release, not an LTS", "vendor": "MariaDB", "what": "MariaDB 13.0, a non-LTS \"rolling\" release that shipped on 15 September 2026, reaches end of life on 31 December 2026 — roughly three and a half months of maintenance, after which the 13.0 series gets no further releases", "category": "Runtime", "sunsetDate": "2026-12-31", "status": "confirmed", "impact": "MariaDB 13.0 is a non-LTS release: it shipped on 15 September 2026 and its maintenance window ends on 31 December 2026, about three and a half months later. That is by design — MariaDB now ships short-lived \"rolling\" releases between its long-term-support versions, and each one is superseded quickly. The trap is that a `.0` version number reads like a stable milestone when it is the opposite: after 31 December 2026 the 13.0 line receives no further maintenance releases, including security fixes. Anyone who pulled `mariadb:13` or `mariadb:13.0` into a Dockerfile, or installed 13.0 expecting normal support, is on a version that goes unmaintained at the end of the year. Production databases in particular should be on a MariaDB LTS release rather than a rolling one — the current LTS lines are 12.3 (supported to June 2029) and 11.8 (supported to June 2028).", "migration": "If you are running MariaDB 13.0, move to a long-term-support release rather than chasing the next short-term one. MariaDB 12.3 is the newest LTS, supported through 12 June 2029; 11.8 is an earlier LTS supported through 4 June 2028. Both receive maintenance and security updates for years rather than months. In Dockerfiles and compose files, replace `mariadb:13` / `mariadb:13.0` tags with a supported LTS tag such as `mariadb:12.3` or `mariadb:11.8`, and rehearse the upgrade on a copy — check for any changed defaults or deprecated settings between versions before cutting over production. If you specifically need a rolling release for testing new features, that is a legitimate use, but pin the expectation: it will fall out of maintenance within months and must be upgraded continuously.", "alternatives": [ "MariaDB 12.3 (LTS) — supported through 12 June 2029, the longest current runway", "MariaDB 11.8 (LTS) — supported through 4 June 2028" ], "detect": [ "image:mariadb:13.0", "image:mariadb:13" ], "source": { "url": "https://endoflife.date/mariadb", "label": "MariaDB support lifecycle — endoflife.date (tracks upstream maintenance windows)" }, "updated": "2026-09-16" }, { "id": "gmail-third-party-account-features-removal", "url": "https://lastcall.dev/entries/gmail-third-party-account-features-removal", "title": "Gmail removes \"Send as\", Gmailify and POP for third-party accounts on the web in January 2027", "vendor": "Google", "what": "Gmail is discontinuing three features for third-party (non-Google) email accounts on the web — \"Send as\" (sending from a non-Google address like an @outlook.com or @yahoo.com account), Gmailify, and POP fetching of external mail into the Gmail web interface — with full removal in January 2027. Google-hosted addresses (Gmail and Workspace) and the Gmail mobile app are not affected.", "category": "Feature", "sunsetDate": "2027-01-01", "status": "confirmed", "impact": "For years Gmail on the web has let you wire up a non-Google email account — an @outlook.com, @yahoo.com, or work address on another provider — and treat Gmail as the front end for it: send outgoing mail so it appears \"from\" that address (\"Send as\"), pull that account's messages into your inbox over POP, and get Gmail's spam and inbox features applied to it (Gmailify). Google is removing all three of those for third-party accounts on the web. Per its support page the rollout is staged: in Q3 2026 affected users get an in-product notification; across Q3–Q4 2026 Gmail may stop allowing new configurations of these features and encourages people to migrate; and in January 2027 the features are fully removed. Who this hits: anyone who runs a non-Google mailbox through Gmail's web interface — people who reply from an old ISP or work address inside Gmail, or who consolidate several external accounts into one Gmail tab. What it does NOT touch: \"Send as\" for Gmail or Google Workspace addresses and aliases keeps working; the Gmail mobile app for Android, iPhone and iPad can still add and use non-Google accounts as before; other clients (Outlook, Thunderbird, Apple Mail) can still reach your Gmail over IMAP/POP; and forwarding from a third-party provider into Gmail is unaffected. The change is specifically about sending from, and fetching into, Gmail on the web for non-Google accounts.", "migration": "Google names three alternatives for keeping access to a third-party account once the web features are gone. Simplest is to use that provider's own website or app directly for sending and reading its mail. If you want everything in one desktop client, set the account up over IMAP/SMTP in a mail app such as Outlook, Thunderbird, or Apple Mail — those protocols are unaffected. And the Gmail mobile app still supports adding non-Google accounts, so a phone or tablet can keep the consolidated-inbox experience the web is losing. Before January 2027, take an inventory: open Gmail's Settings → \"Accounts and Import\" and note every \"Send mail as\" entry and POP account that points at a non-Google address, since those are the ones that stop working on the web. If you rely on sending \"from\" an external address, decide now whether you'll move that sending into the provider's own service or a desktop client, and update any saved filters or workflows that assume the mail flows through Gmail on the web.", "alternatives": [ "The third-party provider's own website or app — Google's first suggested path for sending and reading that account's mail directly", "A desktop mail client (Outlook, Thunderbird, Apple Mail) configured over IMAP/SMTP — unaffected by this change", "The Gmail mobile app — still supports adding and using non-Google accounts" ], "detect": [], "source": { "url": "https://support.google.com/mail/answer/17101213?hl=en", "label": "Learn about changes to third-party email account support in Gmail — Gmail Help (official)" }, "updated": "2026-09-11" }, { "id": "openai-audio-realtime-models-eol", "url": "https://lastcall.dev/entries/openai-audio-realtime-models-eol", "title": "OpenAI deprecates its legacy audio, realtime, and transcription models", "vendor": "OpenAI", "what": "OpenAI has deprecated a family of older audio, realtime, and speech-to-text API models — including gpt-realtime, gpt-audio, and the gpt-4o audio/realtime line — and will remove them from the API on 20 January 2027", "category": "API", "sunsetDate": "2027-01-20", "status": "confirmed", "impact": "On 20 July 2026 OpenAI marked a group of its voice and speech models as deprecated, and set 20 January 2027 as the date they stop responding in the API. The affected models are the ones many voice apps call directly: gpt-realtime and gpt-realtime-mini (the low-latency speech-to-speech models behind live voice agents), gpt-audio and gpt-audio-mini (audio-in/audio-out chat), the older gpt-4o-audio, gpt-4o-realtime, gpt-4o-mini-audio and gpt-4o-mini-realtime snapshots, and the gpt-4o-mini-transcribe-2025-03-20 transcription snapshot. Deprecated means they still work for now; on the shutdown date, calls that name one of these models start failing. Anything that hardcodes one of these model IDs — a phone-support bot, a live-captioning feature, a voice assistant, a transcription pipeline — will error on 20 January 2027 unless the model string is updated before then. Nothing changes on the day you read this; the six-month window is the runway to swap identifiers and re-test.", "migration": "OpenAI publishes a direct replacement for each retired model, so this is a rename rather than a re-architecture in most cases. gpt-realtime and gpt-4o-realtime map to gpt-realtime-2.1; gpt-realtime-mini and gpt-4o-mini-realtime map to gpt-realtime-2.1-mini; gpt-audio, gpt-4o-audio, gpt-audio-mini and gpt-4o-mini-audio all map to gpt-audio-1.5; and gpt-4o-mini-transcribe-2025-03-20 maps to gpt-4o-mini-transcribe-2025-12-15. Find every place your code pins one of the old model IDs (search your codebase and any config/prompt store for the exact strings), point it at the replacement, and re-run your voice/transcription test suite — newer model versions can shift latency, voice characteristics, and token accounting even when the API shape is unchanged. Teams that would rather not chase OpenAI's model cadence can evaluate other realtime-speech and speech-to-text providers, but that is a larger migration than swapping a string.", "alternatives": [ "gpt-realtime-2.1 / gpt-realtime-2.1-mini — OpenAI's named realtime replacements", "gpt-audio-1.5 — OpenAI's named audio replacement", "gpt-4o-mini-transcribe-2025-12-15 — the current transcription snapshot" ], "detect": [ "text:gpt-realtime", "text:gpt-realtime-mini", "text:gpt-audio", "text:gpt-audio-mini", "text:gpt-4o-audio", "text:gpt-4o-realtime", "text:gpt-4o-mini-audio", "text:gpt-4o-mini-realtime", "text:gpt-4o-mini-transcribe-2025-03-20" ], "source": { "url": "https://developers.openai.com/api/docs/deprecations", "label": "Deprecations — OpenAI API (official)" }, "updated": "2026-07-26" }, { "id": "azure-blueprints-retirement", "url": "https://lastcall.dev/entries/azure-blueprints-retirement", "title": "Azure Blueprints is being retired: no new definitions since 31 July 2026, full shutdown 31 January 2027", "vendor": "Microsoft Azure", "what": "Azure Blueprints (Preview) is being retired on a phased timeline — new blueprint definitions can no longer be created as of 31 July 2026, and the service is fully removed on 31 January 2027; Microsoft points teams to Template Specs and Deployment Stacks", "category": "Feature", "sunsetDate": "2027-01-31", "status": "confirmed", "impact": "If you use Azure Blueprints to package ARM templates, policy assignments, and role assignments into repeatable environment definitions, it is being retired. Microsoft has set a phased timeline that has already started: as of 31 July 2026, new blueprint definitions and versions can no longer be created; on 31 October 2026, existing blueprint definitions can no longer be modified and new blueprint assignments can no longer be created; on 31 December 2026, existing blueprint assignments can no longer be modified; and on 31 January 2027, Azure Blueprints is retired outright — the API stops responding, the Azure CLI and Azure PowerShell commands stop functioning, and Blueprints is removed from the Azure portal. Blueprint definitions, versions, and assignments that have not been exported by then are lost. Because it never left preview, Blueprints is easy to forget, but any landing-zone or governance automation that provisions subscriptions through a blueprint is on this clock: after 31 January 2027 the calls that assign or manage those blueprints simply fail.", "migration": "Export and rebuild before 31 January 2027. Microsoft recommends moving existing blueprint definitions and assignments to Deployment Stacks (its recommended successor for managing a resource lifecycle as a unit) and Template Specs (for storing and versioning the ARM templates themselves); blueprint artifacts convert to ARM JSON templates or Bicep files that a deployment stack then deploys. Because the first two phases have already passed, treat this as time-boxed: you cannot author new blueprint definitions any more, and from 31 October you cannot modify the ones you have, so the practical move is to export every blueprint definition and assignment you still rely on now, port each into a Template Spec plus a deployment stack, and validate the redeployment against a test subscription well before the January cut-off. The policy and role assignments a blueprint used to bundle are expressed directly through Azure Policy and RBAC in the new model.", "alternatives": [ "Deployment Stacks — Microsoft's recommended replacement for managing a group of Azure resources as a single lifecycle unit", "Template Specs — store and version the underlying ARM JSON / Bicep templates in Azure", "Azure Policy + RBAC assignments applied directly, for the governance that a blueprint previously bundled" ], "detect": [ "text:Microsoft.Blueprint/blueprints" ], "source": { "url": "https://learn.microsoft.com/en-us/azure/governance/blueprints/blueprint-retirement", "label": "Azure Blueprints retirement — Microsoft Learn (official phased timeline)" }, "updated": "2026-08-16" }, { "id": "osf-projects-phaseout", "url": "https://lastcall.dev/entries/osf-projects-phaseout", "title": "OSF phases out its Projects workspace (storage & collaboration)", "vendor": "Center for Open Science", "what": "The Center for Open Science winds down the OSF Projects workflow — collaboration, file management, and storage — locking new project creation from 16 November 2026 and making all projects read-only after 19 February 2027; preregistration and preprints continue", "category": "SaaS", "sunsetDate": "2027-02-19", "status": "confirmed", "impact": "OSF (the Open Science Framework), run by the Center for Open Science, is used by researchers both to preregister and share studies and as a general workspace for collaboration, file management, and storage. The Center is phasing out that workspace side of OSF, citing a challenging funding environment for open research infrastructure, and moving toward an integrated model with complementary services. Two dated steps: from 16 November 2026, no new projects or child components of existing projects can be created, and OSF stops accepting newly uploaded files into private storage; after 19 February 2027, all public and private OSF projects become read-only. What is NOT going away: study planning and preregistration via OSF Registries, preprint sharing, cross-repository linking of research outputs, and access to existing public projects — and all links and DOI identifiers continue to resolve indefinitely. The loss is specifically the ability to use OSF Projects as a live workspace: after the read-only date you can no longer add, edit, or share newly uploaded data, materials, or code there. Anyone using OSF as their active file store or collaboration hub for ongoing research needs to move that work elsewhere.", "migration": "If you use OSF Projects as an active workspace, move ongoing work to another repository, storage location, or workflow tool before the deadlines — new project creation and new private-storage uploads stop on 16 November 2026, and editing stops entirely when projects go read-only after 19 February 2027, so start well ahead of those dates. The Center specifically names Zenodo (the CERN-hosted repository for data, materials, and code) as a complementary service, and points users to its help guides for choosing an appropriate repository. You do not need to migrate for the sake of preserving links: existing public projects stay accessible and all DOIs and links keep resolving indefinitely. You migrate to keep a live place to create, edit, and share new work.", "alternatives": [ "Zenodo (CERN-hosted) — named by the Center as a complementary repository for data, materials, and code", "OSF Registries — retained on OSF for study planning and preregistration", "OSF Preprints — retained for sharing preprints", "An institutional or discipline-specific data repository / storage tool for active collaboration" ], "detect": [], "source": { "url": "https://www.cos.io/osf-changes", "label": "OSF Changes — Center for Open Science (official)" }, "updated": "2026-08-12" }, { "id": "openai-transcription-models-eol", "url": "https://lastcall.dev/entries/openai-transcription-models-eol", "title": "OpenAI deprecates whisper-1 and its gpt-4o-transcribe speech-to-text models", "vendor": "OpenAI", "what": "OpenAI has deprecated its older speech-to-text API models — whisper-1, gpt-4o-transcribe, gpt-4o-mini-transcribe, and gpt-4o-transcribe-diarize — and will remove them from the API on 26 February 2027", "category": "API", "sunsetDate": "2027-02-26", "status": "confirmed", "impact": "On 26 August 2026 OpenAI notified developers that four transcription (speech-to-text) models are deprecated and will stop responding in the API on 26 February 2027: whisper-1 (the long-standing Whisper transcription endpoint), gpt-4o-transcribe and gpt-4o-mini-transcribe (the GPT-4o-based transcription models), and gpt-4o-transcribe-diarize (the variant that labels who is speaking). Deprecated means they still work today; on the shutdown date, any API call that names one of these models starts failing. Anything that hardcodes one of these model IDs — a meeting-transcription pipeline, a voice-note or podcast transcriber, a call-center analytics job, an accessibility captioning feature — will error on 26 February 2027 unless the model string is updated first. This is the transcription counterpart to OpenAI's legacy audio and realtime deprecation (shutdown 20 January 2027); note that whisper-1 here is the hosted OpenAI API model, not the open-weight Whisper you can run yourself, which is unaffected.", "migration": "OpenAI points every retired transcription model to the same two replacements: gpt-live-transcribe or gpt-transcribe (see OpenAI's transcription guide). Find every place your code or config pins one of the old model IDs — search your codebase, prompt store, and any environment/config for the exact strings whisper-1, gpt-4o-transcribe, gpt-4o-mini-transcribe, and gpt-4o-transcribe-diarize — point them at gpt-live-transcribe or gpt-transcribe, and re-run your transcription tests. Newer models can shift accuracy, latency, timestamp/segment formatting, and token accounting even when the request shape is unchanged, and diarization behaviour in particular is worth re-validating if you relied on gpt-4o-transcribe-diarize. Teams that would rather not track OpenAI's model cadence can self-host open-weight Whisper or evaluate another speech-to-text provider, but that is a larger migration than swapping a model string.", "alternatives": [ "gpt-live-transcribe — OpenAI's named transcription replacement", "gpt-transcribe — OpenAI's named transcription replacement", "Self-hosted open-weight Whisper, or another speech-to-text provider — a larger migration off OpenAI's hosted models" ], "detect": [ "text:whisper-1", "text:gpt-4o-transcribe", "text:gpt-4o-mini-transcribe", "text:gpt-4o-transcribe-diarize" ], "source": { "url": "https://developers.openai.com/api/docs/deprecations", "label": "Deprecations — OpenAI API (official)" }, "updated": "2026-09-10" }, { "id": "amazon-workmail-end-of-support", "url": "https://lastcall.dev/entries/amazon-workmail-end-of-support", "title": "Amazon WorkMail end of support — the managed email and calendar service shuts down 31 March 2027", "vendor": "Amazon Web Services", "what": "AWS is ending support for Amazon WorkMail, its managed business email and calendar service. WorkMail stops accepting new customers on 30 April 2026, and on 31 March 2027 existing customers can no longer use it or access the WorkMail console and resources. AWS points customers to third-party email services and a mailbox export path.", "category": "SaaS", "sunsetDate": "2027-03-31", "status": "confirmed", "impact": "Amazon WorkMail is AWS's managed business email and calendar service — Exchange-compatible mailboxes hosted in AWS, reachable over IMAP/SMTP, Outlook, the WorkMail web client, and Exchange ActiveSync, often wired into an AWS Directory Service or Microsoft AD setup. AWS is shutting it down. On its official end-of-support page AWS says the decision is \"effective March 31, 2027\", that WorkMail \"will no longer accept new customers beginning April 30, 2026\", and that existing customers who signed up before that date can keep using it until the end date — after which \"you will no longer be able to use Amazon WorkMail\" or access the WorkMail console and resources. This is a full service retirement, not a version bump: organizations that run their company mailboxes on WorkMail need to migrate every mailbox to another provider and cut over MX/mail routing before the cutoff, or lose access to their mail. Two dates matter — 30 April 2026 (no new organizations or accounts can be created on WorkMail) and 31 March 2027 (the hard end for everyone). The exposure is anything that depends on WorkMail: user and resource mailboxes, calendar data, any application that sends or reads mail through the WorkMail Message Flow or WorkMail APIs, and automation built on the WorkMail SDK/CLI.", "migration": "Plan a mailbox migration off WorkMail well before 31 March 2027, and note the earlier 30 April 2026 date if you were counting on creating new WorkMail organizations — after it, you cannot. AWS recommends moving to third-party email services and names Kopano Cloud, Zoho Mail, and Zoom Mail as comparable options \"with tooling for easy migration\", while noting you can also move to any other in-market solution (Microsoft 365 and Google Workspace being the obvious mainstream choices). Export first: AWS points to its mailbox export guide so you can pull each mailbox's content out before the service goes away. The practical sequence is to stand up the new email platform, migrate mailboxes and calendars, repoint your domain's MX (and SPF/DKIM/DMARC) records, and then decommission WorkMail. If you have code or automation on the WorkMail APIs — for example the WorkMail Message Flow used to intercept or process inbound and outbound mail — retarget that to the new provider's equivalent (or to SES for programmatic sending) as part of the move.", "alternatives": [ "Kopano Cloud, Zoho Mail, or Zoom Mail — the third-party services AWS names as comparable, with migration tooling", "Microsoft 365 or Google Workspace — mainstream managed email/calendar suites to migrate mailboxes to", "Amazon SES — for the programmatic email-sending piece if you only used WorkMail's APIs to send mail" ], "detect": [ "npm:@aws-sdk/client-workmail", "npm:@aws-sdk/client-workmailmessageflow" ], "source": { "url": "https://docs.aws.amazon.com/workmail/latest/adminguide/workmail-end-of-support.html", "label": "Amazon WorkMail end of support — AWS Administrator Guide (official)" }, "updated": "2026-09-11" }, { "id": "oracle-jdk-27-end-of-life", "url": "https://lastcall.dev/entries/oracle-jdk-27-end-of-life", "title": "Oracle JDK 27 reaches end of life on 31 March 2027 — a six-month non-LTS release", "vendor": "Oracle", "what": "Oracle JDK 27, a non-LTS feature release that shipped on 15 September 2026, reaches end of life on 31 March 2027 — after which it receives no further Oracle updates, including security patches, and developers are expected to move to the next release or to an LTS line", "category": "Runtime", "sunsetDate": "2027-03-31", "status": "confirmed", "impact": "Oracle JDK 27 is a non-LTS feature release: it shipped on 15 September 2026 and Oracle's free updates for it end on 31 March 2027, when the next feature release (JDK 28) arrives. That six-month window is the standard cadence for non-LTS JDKs — Oracle ships a feature release every March and September, and only every fourth one is a Long-Term-Support version. After 31 March 2027 there are no further Oracle updates for 27, including security patches; you are expected to have moved to JDK 28 or to sit on an LTS release instead. The practical risk is treating a non-LTS JDK like a stable target: a service pinned to JDK 27 in production is on a runtime that stops getting security fixes at the end of Q1 2027. For long-lived applications the right target is an LTS release — JDK 25 (supported to September 2030) or JDK 21 (September 2028) — rather than following each six-month feature release.", "migration": "For anything long-lived, run on an Oracle JDK LTS release rather than a non-LTS one. JDK 25 is the current LTS, with Oracle updates through September 2030; JDK 21 is the previous LTS, through September 2028. Both give years of patches instead of six months. If you deliberately track the latest features on the non-LTS train, plan to move from 27 to 28 promptly when 28 ships in March 2027, and keep doing so every six months — a non-LTS JDK is only safe if it is upgraded continuously. Note that these dates are for Oracle's JDK builds specifically; other distributions (Eclipse Temurin/Adoptium, Amazon Corretto, Azul, Microsoft Build of OpenJDK) publish their own support timelines, so if you run one of those, check its schedule rather than assuming Oracle's dates apply.", "alternatives": [ "Oracle JDK 25 (LTS) — Oracle updates through September 2030, the longest runway", "Oracle JDK 21 (LTS) — Oracle updates through September 2028", "A non-Oracle OpenJDK distribution (Eclipse Temurin, Amazon Corretto, Azul, Microsoft) with its own LTS support timeline" ], "detect": [], "source": { "url": "https://endoflife.date/oracle-jdk", "label": "Oracle JDK release lifecycle — endoflife.date (tracks Oracle's update schedule)" }, "updated": "2026-09-16" }, { "id": "azure-app-service-node-22-lts-eol", "url": "https://lastcall.dev/entries/azure-app-service-node-22-lts-eol", "title": "Azure App Service ends support for Node 22 LTS on 30 April 2027", "vendor": "Microsoft Azure", "what": "Microsoft is ending support for the Node.js 22 LTS runtime on Azure App Service on 30 April 2027; apps keep running but stop receiving security updates and customer support, and Microsoft directs developers to upgrade to Node 24 LTS", "category": "SaaS", "sunsetDate": "2027-04-30", "status": "confirmed", "impact": "This is the Azure App Service runtime end-of-support, not the end of Node.js 22 itself. If you host a Node app on Azure App Service pinned to the Node 22 LTS runtime stack, Microsoft says that on 30 April 2027 support for Node 22 LTS ends: your apps \"will continue to run, but security updates will no longer be available, and we'll no longer provide customer service for Node 22 LTS.\" In practice that means a running app is not switched off, but the platform stops patching the Node 22 runtime underneath it, so you accumulate unpatched runtime CVEs and lose Microsoft support for any Node-22-specific issue. This tracks the upstream Node.js release calendar — Node 22 is the current \"Jod\" LTS line and its own community end-of-life is scheduled for April 2027 — so App Service is retiring the stack in step with upstream rather than early.", "migration": "Microsoft's required action is to upgrade affected App Service apps to Node 24 LTS before 30 April 2027 (its upgrade steps are at aka.ms/nodeversion, and the runtime support policy at learn.microsoft.com/azure/app-service/language-support-policy). Practically: find every App Service app whose runtime stack is set to Node 22 (in the Azure Portal under Configuration → General settings → Stack settings, or the linuxFxVersion / WEBSITE_NODE_DEFAULT_VERSION setting in your infrastructure-as-code), test your app against Node 24 in a staging slot, update the app's engines/CI to Node 24, and roll it out via a deployment slot swap so you can fall back if something breaks. Node 24 became the active LTS line in October 2025, so libraries and build tooling largely support it already; watch for native-addon rebuilds and any dependency that has not yet published Node 24-compatible binaries. There is a long runway here — the point of logging it now is so the upgrade lands as routine maintenance rather than a scramble in April 2027.", "alternatives": [ "Node 24 LTS on Azure App Service — Microsoft's named upgrade target (aka.ms/nodeversion)", "Containerize the app and deploy your own pinned Node image to App Service or Azure Container Apps if you need a specific runtime version" ], "detect": [], "source": { "url": "https://azure.microsoft.com/updates?id=567334", "label": "Retirement: Support for Node 22 LTS ends on April 30, 2027 — Microsoft Azure Updates (id 567334)" }, "updated": "2026-08-25" }, { "id": "hcp-vagrant-eol", "url": "https://lastcall.dev/entries/hcp-vagrant-eol", "title": "HCP Vagrant Registry is shutting down — boxes must move off by 7 June 2027", "vendor": "HashiCorp", "what": "HashiCorp is retiring HCP Vagrant, its hosted Vagrant box registry. New box and registry creation ends 14 December 2026, support ends 15 March 2027, and all operations cease on 7 June 2027, after which hosted boxes are decommissioned. The Vagrant CLI and community edition are not affected.", "category": "SaaS", "sunsetDate": "2027-06-07", "status": "confirmed", "impact": "HCP Vagrant Registry is the hosted service where Vagrant users publish, version, and download \"boxes\" — the base VM images a Vagrantfile pulls to spin up a development environment. It is the successor to Vagrant Cloud, which HashiCorp migrated into HCP. Now HashiCorp is winding the hosted registry down entirely, on a staged timeline: new box and registry creation ends 14 December 2026; support and maintenance end 15 March 2027; and on 7 June 2027 operations end and hosted boxes are decommissioned. The important scope limit: this is only the hosted HCP Vagrant service. Vagrant itself — the open-source CLI and the community edition on GitHub — is not going away; you can still build boxes locally and share them from a location you host yourself. What disappears is HashiCorp's hosted place to store and distribute those boxes, along with the free public hosting many teams and box publishers have relied on. Anyone whose Vagrantfiles reference boxes hosted on HCP Vagrant, or who publishes boxes for others to consume, needs a new home for those artifacts before 7 June 2027.", "migration": "Start by taking inventory: find everywhere your organization references HCP Vagrant Registry — Vagrantfiles that pull hosted boxes, CI that provisions from them, and any boxes you publish for others. Then decide where those boxes should live. HashiCorp's guidance is that boxes move to customer-hosted storage; common targets are object storage such as AWS S3, Azure Blob Storage, or another provider you control, with Vagrant configured to fetch boxes from there. Note the two intermediate dates while you plan: after 14 December 2026 you can no longer create new boxes or registries on HCP, and after 15 March 2027 the service is unsupported, so treat those as the practical windows to finish publishing and to complete testing of your new hosting. The hard deadline is 7 June 2027, when hosted boxes are decommissioned. Because the CLI and local box building continue, this is a migration of where artifacts are stored, not a change to how Vagrant itself works — but you do take on the hosting (and its cost) yourself.", "alternatives": [ "Self-hosted object storage (AWS S3, Azure Blob Storage, or similar) as the new home for your Vagrant boxes, fetched directly by the Vagrant CLI", "The Vagrant community edition / CLI on GitHub — unaffected; keeps building boxes locally and sharing them from a location you host" ], "detect": [], "source": { "url": "https://developer.hashicorp.com/hcp/docs/vagrant/hcp-vagrant-eol", "label": "HCP Vagrant end of life — HashiCorp Developer (official)" }, "updated": "2026-08-07" }, { "id": "azure-vmware-solution-license-included-retirement", "url": "https://lastcall.dev/entries/azure-vmware-solution-license-included-retirement", "title": "Azure VMware Solution license-included service is being retired: PayGo SKUs on 15 October 2026, all license-included services on 30 August 2027 — move to VCF BYOL", "vendor": "Microsoft Azure", "what": "Azure VMware Solution (AVS) retires its license-included offering — the pay-as-you-go (PayGo) license-included SKUs on 15 October 2026 and all remaining license-included services (including Reserved Instance SKUs and the AV36 SKU) on 30 August 2027 — forcing customers onto the AVS VCF bring-your-own-license (BYOL) model with portable Broadcom VMware Cloud Foundation licenses", "category": "SaaS", "sunsetDate": "2027-08-30", "status": "confirmed", "impact": "If you run Azure VMware Solution on a license-included SKU — where the VMware Cloud Foundation (VCF) license is bundled into the Azure price you pay Microsoft — that offering is being retired on a phased timeline, a downstream effect of Broadcom's November 2025 change requiring \"bring your own\" portable VCF licensing across all hyperscalers. Two dates matter: the license-included pay-as-you-go (PayGo) SKUs retire on 15 October 2026, and all remaining license-included services — including the Reserved Instance (RI) SKUs and the AV36 SKU — retire on 30 August 2027. Customers on license-included RI SKUs must purchase portable Broadcom VCF licenses and transition to an AVS VCF BYOL SKU, or exit AVS entirely, before 30 August 2027 to avoid service disruption on 31 August 2027. This is not AVS itself shutting down — the service continues under the BYOL model — but the bundled-license commercial model most existing customers bought on is going away, so this is a forced re-purchasing and SKU migration with real procurement lead time, not just a config change.", "migration": "Before your applicable date, move to the AVS VCF BYOL SKU: purchase portable VMware Cloud Foundation licenses from Broadcom and transition your AVS environment to the bring-your-own-license SKU, or plan an exit from AVS. Microsoft's explicit guidance is to allow plenty of time, because the constraint is Broadcom license procurement, not an Azure-side toggle: start assessing your current AVS environment immediately and build a transition roadmap. For RI customers, Microsoft allows exchanging reservations with expiration dates beyond 30 August 2027. PayGo customers have the nearer deadline (15 October 2026), so if you are running license-included AVS on pay-as-you-go, treat that as the date on your clock. Teams evaluating whether to stay should use this as a decision point on modernization versus continuing on AVS under the new licensing economics.", "alternatives": [ "Azure VMware Solution VCF BYOL SKU — continue on AVS by bringing portable Broadcom VMware Cloud Foundation licenses purchased from Broadcom", "Exit AVS and modernize onto native Azure services, if a transition roadmap makes that viable before the retirement date" ], "detect": [], "source": { "url": "https://azure.microsoft.com/updates?id=569535", "label": "Retirement: Azure VMware Solution License-included service will be retired August 30, 2027 — Azure Updates (id 569535)" }, "updated": "2026-08-20" }, { "id": "instantdb-cloud-shutdown", "url": "https://lastcall.dev/entries/instantdb-cloud-shutdown", "title": "InstantDB (Instant Cloud) is shutting down after the team joins OpenAI", "vendor": "Instant", "what": "Instant, the open-source realtime database and backend-as-a-service, is winding down its hosted Instant Cloud after the team joins OpenAI — new signups are closed and all cloud apps shut down on 31 August 2027, with self-hosting the migration path", "category": "SaaS", "sunsetDate": "2027-08-31", "status": "confirmed", "impact": "Instant (InstantDB) is a realtime, client-side database and backend-as-a-service — a Firebase-style stack with a reactive database, auth, storage, a sync engine, and admin SDK, consumed through the `@instantdb/react`, `@instantdb/core`, `@instantdb/admin`, and `@instantdb/react-native` packages. The team has announced it is joining OpenAI, and the hosted **Instant Cloud** service is winding down. New signups are already closed. **On 31 August 2027 all cloud apps shut down**; existing users are told to migrate off Instant Cloud within roughly the next 12 months. Backups stay available for a further 12 months, until **31 August 2028**, and any subscription started after 31 July 2026 is being fully refunded. The important nuance is that only the *hosted* service is ending: Instant is fully open source, so this is a hosting shutdown, not a dead product. Any app that reads and writes through Instant Cloud — the default hosted backend most Instant apps use — stops working on the cloud cutoff unless it has been moved to a self-hosted Instant instance or another backend first. Because the SDKs point at Instant Cloud by default, a project can depend on it without anyone having flagged it as a hosted dependency, which is exactly the kind of thing that surfaces late.", "migration": "You have real runway — until 31 August 2027 for live apps, and backups through 31 August 2028 — but the safe move is to plan the migration now rather than in the final months. Because all of Instant is open source, the vendor's recommended path is to **self-host Instant**: they have published a self-hosting and migration guide, and the SDK surface (`@instantdb/react`, `@instantdb/core`, `@instantdb/admin`) stays the same, so the change is repointing your app at your own Instant server rather than rewriting your data layer. Stand up a self-hosted instance (VPS, AWS, or your own infra), migrate your data and verify auth/storage/sync against it, then cut the client config over well before the cloud shutdown. If you would rather leave Instant entirely, budget for a larger rewrite onto another realtime BaaS or database (see alternatives), since that means re-implementing the reactive queries, auth, and sync your app relies on. Either way, export and keep a copy of your data before the 31 August 2028 backup deadline.", "alternatives": [ "Self-host Instant — it is fully open source; the official guide keeps the same SDKs and repoints them at your own server (the vendor-recommended path)", "Another realtime backend-as-a-service (e.g. Supabase, Firebase / Firestore, Convex, PocketBase, Appwrite) — a larger rewrite of queries, auth, and sync", "A conventional database plus your own sync/realtime layer, if you want full control over hosting and data" ], "detect": [ "npm:@instantdb/react", "npm:@instantdb/core", "npm:@instantdb/admin", "npm:@instantdb/react-native" ], "source": { "url": "https://www.instantdb.com/essays/instant_team_joins_openai", "label": "The Instant team joins OpenAI — Instant (official announcement)" }, "updated": "2026-08-27" }, { "id": "google-assistant-mobile-sunset", "url": "https://lastcall.dev/entries/google-assistant-mobile-sunset", "title": "Google Assistant is being retired on mobile in favor of Gemini — removal reportedly begins 4 September 2026", "vendor": "Google", "what": "Google is discontinuing the classic Google Assistant on mobile devices — phones, tablets, Wear OS watches, compatible headphones, and phone-projected Android Auto — replacing it with Gemini; Google's public post says this happens \"later this year,\" and Google's emails to users (reported 4 August) say removal begins 4 September 2026", "category": "SaaS", "sunsetDate": null, "status": "signaled", "impact": "Google Assistant is the built-in voice assistant on a very large share of Android phones and tablets, Wear OS watches, many compatible headphones and earbuds, and Android Auto when it is projected from a phone. Google is replacing it with Gemini, its newer AI assistant. On its official blog Google states only that \"over the coming months\" it is upgrading more mobile users to Gemini, and that \"later this year\" the classic Assistant will no longer be accessible on most mobile devices — no exact date appears on that page. Separately, beginning 4 August 2026, Google emailed Assistant users (reported by 9to5Google, Search Engine Land, Android Authority and Engadget, which quote the notice) telling them it will begin removing access to Google Assistant starting 4 September 2026, with the rollout taking a few weeks to reach everyone. The change is described as one-way: once a device moves to Gemini, the reporting says you cannot switch back to Assistant on that device or its paired accessories. For most people nothing must be done — Gemini takes over automatically — but the swap is not feature-for-feature, and some Assistant capabilities (press reports name Interpreter Mode and certain smart-home routines) are described as not carrying across, so anyone who depends on a specific Assistant behavior should check whether Gemini supports it before their device flips.", "migration": "No action is required to keep a working voice assistant: Gemini replaces Google Assistant automatically on affected devices, and Google positions it as supporting the most-requested tasks such as playing music, setting timers, and acting from the lock screen. The work, where there is any, is in the gaps. If you rely on a particular Assistant feature — Interpreter Mode, a specific Routine, a smart-home or third-party action — confirm Gemini handles it before the change reaches your device, because the reported switch to Gemini cannot be reversed on that device. Older or low-memory Android devices are reported to keep a legacy Assistant for basic tasks rather than moving to Gemini. Not affected for now: cars with Google built-in, and home devices — speakers, smart displays, and TVs — which Google says will keep running Assistant until a separate, later Gemini experience arrives for them. There is no data-export deadline here in the way a shutting-down cloud service has one; the thing to protect is any workflow or accessibility feature that lives specifically in Assistant and may not exist in Gemini yet.", "alternatives": [ "Gemini — Google's own replacement; it becomes the default assistant on affected mobile devices automatically", "On home devices (speakers, displays, TVs) and cars with Google built-in, Assistant continues to work for now — no immediate change there", "Third-party voice assistants where a needed Assistant feature is not yet available in Gemini" ], "detect": [], "source": { "url": "https://blog.google/products-and-platforms/products/gemini/google-assistant-gemini-mobile/", "label": "The Assistant experience on mobile is upgrading to Gemini — blog.google (Google)" }, "updated": "2026-09-04" }, { "id": "kotlin-notebook-sunset", "url": "https://lastcall.dev/entries/kotlin-notebook-sunset", "title": "JetBrains is sunsetting Kotlin Notebook, unbundling it from IntelliJ IDEA 2026.2", "vendor": "JetBrains", "what": "JetBrains will stop maintaining Kotlin Notebook as a product: from IntelliJ IDEA 2026.2 it is unbundled and gets no new features, and no compatible plugin will be published for 2026.3 and beyond; the source moves to open source", "category": "Feature", "sunsetDate": null, "status": "confirmed", "impact": "Kotlin Notebook is the interactive, cell-based scratchpad JetBrains built into IntelliJ IDEA for exploring Kotlin code, prototyping, and working with data inline. JetBrains has announced it will sunset it as a maintained product. The transition is marked by IDE version, not a calendar date: through v2026.1 it stays bundled; in v2026.2 it is unbundled from IntelliJ IDEA and stops receiving new features; for v2026.3 and later JetBrains will not publish a compatible plugin at all. Nothing breaks immediately — if you use Kotlin Notebook today it keeps working, and for v2026.2 the plugin is still installable from the marketplace. What ends is JetBrains' maintenance: the tool freezes, and once you move to 2026.3+ there is no vendor-supported build. Because JetBrains gave a version boundary rather than a specific day, this entry carries no exact countdown — the honest status is that the plan is confirmed while no calendar date applies. JetBrains attributes the change to shifting demand for built-in interactive tooling and to AI tools reshaping how developers prototype and iterate.", "migration": "JetBrains points users toward Kotlin DataFrame, noting that with the Kotlin DataFrame compiler plugin its schema-aware APIs and generated column accessors now work directly in regular Gradle and Maven projects rather than only inside a notebook. The Kotlin Notebook plugin itself is not being deleted: JetBrains says the source will be published on GitHub under the Apache License 2.0 so the community can continue development, and the existing plugin remains installable from the marketplace and compatible with v2026.2. Teams that depend on notebook-style Kotlin workflows should decide before upgrading to 2026.3 whether to follow the community-maintained open-source plugin, move exploratory work into Kotlin DataFrame in normal projects, or use a general-purpose notebook environment such as Jupyter with a Kotlin kernel.", "alternatives": [ "Kotlin DataFrame (with the compiler plugin) for schema-aware data work directly in Gradle/Maven projects — JetBrains' named direction", "The community-maintained open-source Kotlin Notebook plugin, once published on GitHub (Apache 2.0)", "Jupyter with the Kotlin kernel for general notebook-style exploration" ], "detect": [], "source": { "url": "https://blog.jetbrains.com/idea/2026/06/kotlin-notebook-sunset/", "label": "Kotlin Notebook Sunset — The JetBrains Blog (official)" }, "updated": "2026-07-29" }, { "id": "mongock-eol", "url": "https://lastcall.dev/entries/mongock-eol", "title": "Mongock enters maintenance mode, end-of-life at the end of 2026", "vendor": "Mongock", "what": "Mongock, the Java/Spring change-management tool for MongoDB, stops feature development now and reaches end-of-life at the end of 2026; its makers point users to a successor, Flamingock", "category": "Library", "sunsetDate": null, "status": "confirmed", "impact": "Mongock is the tool many Java and Spring Boot teams use to version and apply schema/data migrations (\"change units\") against MongoDB, the way Flyway or Liquibase work for SQL. Its maintainers have announced it is in maintenance mode as of this announcement and will reach end-of-life at the end of 2026. Until then it still receives critical bug fixes and security updates; after that the project stays downloadable but gets no more fixes, security patches, or features — all new development has moved to a successor, Flamingock, built by the same team. Nothing breaks the day you read this: an app that already depends on Mongock keeps running and keeps applying its existing change units. What ends is the maintenance track, so over 2027 an app pinned to Mongock accumulates unpatched issues in its migration layer and drifts off supported ground. No exact end-of-2026 date has been given, so treat \"end of 2026\" as the window, not a precise cutoff.", "migration": "The maintainers position Flamingock as the migration target and say it imports Mongock's existing audit history and recognises already-executed change units, so it continues where Mongock left off rather than re-running past migrations. They describe the typical move as a single dependency swap and a single annotation, leaving existing change units untouched — but it is a successor, not a drop-in, so validate it against your own migration suite in a non-production environment before trusting it in a deploy path. Teams that prefer to leave the Mongock ecosystem entirely can evaluate general-purpose migration tooling, though most MongoDB-specific change-management features are particular to this lineage.", "alternatives": [ "Flamingock — the maintainers' named successor, which imports Mongock audit history", "Liquibase (has a MongoDB extension) for teams standardising on one migration tool across databases" ], "detect": [], "source": { "url": "https://flamingock.io/blog/sunsetting-mongock/", "label": "Sunsetting Mongock — flamingock.io (the maintainers)" }, "updated": "2026-07-25" }, { "id": "pycharm-low-usage-plugins-deprecation", "url": "https://lastcall.dev/entries/pycharm-low-usage-plugins-deprecation", "title": "PyCharm deprecates and unbundles low-usage plugins — Databricks, Hugging Face, Data Wrangler, and more", "vendor": "JetBrains", "what": "PyCharm unbundles and stops maintaining a set of low-usage bundled plugins — Data Wrangler, Hugging Face, Google Colab, Spark/PySpark support, AI Playground, AI Agents Debugger, and Databricks", "category": "Feature", "sunsetDate": null, "status": "signaled", "impact": "Starting with PyCharm 2026.2, JetBrains removes seven bundled plugins from the IDE and stops developing or maintaining them: Data Wrangler, Hugging Face, Google Colab (Jupyter Notebook Colab), Spark including PySpark support, AI Playground, AI Agents Debugger, and Databricks. If you rely on any of them, they no longer ship inside PyCharm — you have to install a compatible version yourself from the JetBrains Marketplace. That compatible version stays available and works with 2026.2, but from PyCharm 2026.3 onward JetBrains stops publishing compatible builds, so the plugin will only continue to exist if the community keeps it alive through the Obsolete Plugins repository. This mainly bites data and ML workflows: teams that open Databricks, run PySpark, browse Hugging Face models, or use Data Wrangler / Google Colab from inside PyCharm rather than a browser.", "migration": "On PyCharm 2026.2, reinstall any plugin you need from the JetBrains Marketplace (Settings → Plugins → Marketplace) — the compatible version is still published there and works with 2026.2. Do this before upgrading to 2026.3, because from that release JetBrains no longer publishes compatible builds. The source for each unbundled plugin moves to JetBrains' public Obsolete Plugins repository, where you (or the community) can build and install it manually with a fixed compatibility range. JetBrains has invited maintainers to adopt individual plugins.", "alternatives": [ "JetBrains Marketplace — reinstall a compatible plugin version (works on PyCharm 2026.2)", "JetBrains Obsolete Plugins repository — community-maintained source for manual builds", "Use the vendor's own tooling directly (e.g. Databricks / Hugging Face / Google Colab in the browser or CLI)" ], "detect": [], "source": { "url": "https://blog.jetbrains.com/pycharm/2026/08/unbundling-and-deprecating-low-usage-plugins-in-pycharm/", "label": "Unbundling and Deprecating Low-Usage Plugins in PyCharm — The JetBrains Blog (August 2026)" }, "updated": "2026-08-13" }, { "id": "python-3-10-eol", "url": "https://lastcall.dev/entries/python-3-10-eol", "title": "Python 3.10 end-of-life", "vendor": "Python", "what": "Python 3.10 stops receiving security fixes", "category": "Runtime", "sunsetDate": null, "status": "signaled", "impact": "After its end-of-life, Python 3.10 stops receiving security fixes. Projects pinned to 3.10 should plan to move to a supported release (3.11+) before then, especially anything internet-facing. Python publishes the month — October 2026 — but not a day, so treat it as \"some time in October\" rather than a deadline you can schedule a change freeze around.", "migration": "Upgrade to Python 3.11, 3.12, 3.13 or 3.14. Most 3.10 code runs unchanged; check C-extension wheels and any deprecations flagged in the \"What's New\" notes for the target version.", "alternatives": [ "Python 3.11 (security fixes to October 2027)", "Python 3.12 / 3.13 / 3.14 (supported)" ], "detect": [ "image:python:3.10", "runtime:python:3.10" ], "source": { "url": "https://devguide.python.org/versions/", "label": "Status of Python versions — devguide.python.org" }, "updated": "2026-07-21" }, { "id": "google-maps-js-heatmap-drawing-removed", "url": "https://lastcall.dev/entries/google-maps-js-heatmap-drawing-removed", "title": "Google Maps JavaScript API removes Heatmap Layer and Drawing Library", "vendor": "Google", "what": "The Maps JavaScript API Heatmap Layer and Drawing Library are no longer supported and have been removed", "category": "API", "sunsetDate": null, "status": "passed", "impact": "As of May 2026, two long-standing Maps JavaScript API features are gone. `google.maps.visualization.HeatmapLayer` (the built-in heatmap overlay) is unavailable — Google cites low customer usage — and the Drawing Library (`google.maps.drawing.DrawingManager`, the interactive shape-drawing tools) is unavailable too. Existing code that constructs either class no longer works; the Drawing Library removal shipped in Maps JavaScript API v3.65.3b (release notes dated 4 June 2026).", "migration": "For heatmaps, Google points to third-party integrations such as deck.gl, which provides its own HeatmapLayer implementation. For drawing tools, switch to an alternative such as Terra Draw. Both replacements sit on top of the map rather than inside the Google library, so the migration is a rewrite of the affected overlay code, not a config change.", "alternatives": [ "deck.gl (heatmaps)", "Terra Draw (drawing tools)" ], "detect": [ "text:visualization.HeatmapLayer", "text:drawing.DrawingManager" ], "source": { "url": "https://developers.google.com/maps/deprecations", "label": "Google Maps Platform deprecations — Google for Developers" }, "updated": "2026-09-09" } ] }