Klasické stránky SharePointu budou od října 2028 jen pro čtení. Co to znamená a jak se připravit

V zářijovém přehledu to byl jeden řádek v tabulce termínů: 1. 10. 2028 – klasické stránky SharePointu jen pro čtení. Vypadá to vzdáleně a nenápadně. Jenže klasické stránky nejsou okrajová věc. Mají je intranety postavené před rokem 2017, týmové weby založené ze staré šablony, wiki s firemními postupy, přenesené weby ze SharePointu Server i stránky, které si kdysi někdo „vylepšil“ v SharePoint Designeru. Microsoft sice ve svém oznámení uvádí, že klasické funkce dnes používá méně než 5 % aktivních tenantů – ale ve firmách, které mají SharePoint patnáct let, je to spíš pravidlo než výjimka.

Tenhle článek shrnuje, co přesně Microsoft oznámil (MC1464926, 31. srpna 2026), koho se to týká a jak se na to připravit, aby se z termínu nestal problém.

Co se mění, ve dvou fázích

Fáze 1 – od 1. března 2027

Pro všechny tenanty:

• Nepůjde zakládat klasické publishingové weby – ani jako samostatné kolekce, ani jako podweby.
• Nepůjde zapnout funkci publikování (publishing feature) na existujících webech.
• Nastavení tenantu AllowClassicPublishingSiteCreation bude natvrdo vypnuté.

Navíc pro tenanty založené od 1. března 2027:

• Nepůjde vytvářet nové klasické stránky.
• Vlastní skripty budou vypnuté a nepůjde je zapnout (DenyAddAndCustomizePages vynuceno).

Fáze 2 – od 1. října 2028

Totéž se rozšíří na všechny ostatní tenanty:

• Klasické stránky vytvořené uživateli budou jen pro čtení. Půjde je otevřít a číst, ale ne upravit. Nové klasické stránky nepůjde vytvořit.
• Vlastní skripty budou vypnuté ve všech tenantech a výjimku už nepůjde nastavit ani dočasně.

Důležité: obsah se nemaže ani nemění. Stránky zůstanou dostupné ke čtení. Jen ztuhnou – a s nimi i všechno, co se na nich dosud udržovalo ručně.

Kterých stránek se to týká

Microsoft vyjmenovává pět typů „klasických stránek vytvořených uživateli“:

Typ	Kde ho typicky najdete
Wiki stránky	domovské stránky starých týmových webů, firemní wiki s postupy a návody
Stránky s webparty (Web Part pages)	nástěnky oddělení, přehledy složené z webpartů seznamů
Blogové stránky	blogové podweby, které se kdysi zakládaly pro novinky týmu
Publishingové stránky	klasické intranety s rozložením stránek (page layouts), Enterprise Wiki
Vlastní ASPX stránky	stránky vytvořené v SharePoint Designeru nebo řešením třetí strany

Co se nemění:

• Moderní stránky a většina řešení na SharePoint Framework (SPFx) fungují dál. Výjimkou jsou webparty SPFx s nastavením requiresCustomScript: true – při zablokovaných skriptech zmizí z výběru i ze stránek.
• Klasická zobrazení seznamů a knihoven a formuláře seznamů zatím v rozsahu nejsou. Microsoft ale výslovně píše, že na ně může dojít „v samostatném harmonogramu“. Skripty vložené do nich přitom pod omezení vlastních skriptů spadají stejně.
• Samotné klasické weby zůstávají. Mnoho z nich jde modernizovat na místě, bez stavby od nuly.

Od března 2027 nepůjde založit web z těchto šablon: Publishing Portal (BLANKINTERNETCONTAINER#0), Publishing Site (CMSPUBLISHING#0), Publishing Site Blank (BLANKINTERNET#0), Enterprise Wiki (ENTERWIKI#0), Enterprise Search Center (SRCHCEN#0), Site Directory (SPSSITES#0), News Home (SPSNHOME#0), Product Catalog (PRODUCTCATALOG#0), Report Center (SPSREPORTCENTER#0) a Topic Area (SPSTOPIC#0). Ostatní klasické šablony se tato změna netýká.

Proč je to větší věc, než vypadá

„Jen pro čtení“ je u živého obsahu stejné jako „konec“. Wiki s pracovním postupem, který se jednou za čtvrt roku aktualizuje, nebo stránka oddělení s kontakty se po 1. 10. 2028 prostě přestane udržovat. Nikdo nedostane chybovou hlášku, obsah jen začne tiše stárnout. Na intranetu je to horší než výpadek, protože si toho nikdo nevšimne.

Domovská stránka bývá klasická i tam, kde to nikdo nečeká. Týmové weby založené ze staré šablony mají jako domovskou stránku typicky wiki stránku (nepřizpůsobené domovské stránky mohl Microsoft už dřív sám převést na moderní, upravené ale zůstaly klasické). Web pak může v knihovnách a seznamech působit moderně, ale jeho úvodní strana pod změnu spadá.

Vlastní skripty končí definitivně. Už dnes se povolení vlastních skriptů na webu do 24 hodin samo vrací na „nepovoleno“. Od října 2028 už nepůjde nastavit ani tohle dočasné povolení. Microsoft píše, že existující skripty fungovat nepřestanou, ale nepůjde je přidat ani upravit. Kdo má na stránkách Script Editor nebo Content Editor s JavaScriptem, nebude moct skripty opravit, až se něco rozbije.

Migrace ze SharePointu Server se komplikuje. Od března 2027 nepůjde přenést klasický publishingový web „tak, jak je“, protože takový web v SharePointu Online nepůjde založit. Klasické stránky přenést půjde, ale po termínu budou jen pro čtení a skriptové prvky se nemusí zachovat. Microsoft doporučuje modernizaci zahrnout přímo do migrace. Upozorňují na to i dodavatelé migračních nástrojů – například ShareGate píše, že tohle omezení obejít neumí.

Jak zjistit, jestli se vás to týká

Microsoft k tomu dává tři zdroje informací a jedno uklidnění: pokud inventura nenajde klasické publishingové weby, klasické stránky ani dotčené skripty, nemusíte dělat nic.

1. Audit v Microsoft Purview. Kategorie SharePoint Classic Activities a události ClassicPageCreated, ClassicPageEdited a ClassicPageViewed ukazují, které klasické stránky lidé skutečně zakládají, upravují a čtou.
2. Microsoft 365 Assessment Tool. Open-source nástroj Microsoftu (PnP), který projde SharePoint Online a vypíše klasické stránky, jejich webparty a odhad, jak dobře půjdou převést. Analýza klasických stránek je ve verzi 1.15 a novější, napojení na data z auditu (až 180 dní zpětně) od verze 1.16. Pro celý tenant potřebuje registrovanou aplikaci s oprávněními jen pro čtení.
3. Přehled webů s vlastními skripty. V SharePoint admin center je v Active sites sloupec Custom script a připravené zobrazení Custom script allowed sites.

Podstatná je kombinace inventury a auditu. Seznam deseti tisíc klasických stránek sám o sobě nic neřeší. Seznam, který říká, že se z nich dvě stě upravuje a tisíc čte, už je plán.

Jak k tomu přistoupit

Ne všechno je potřeba převádět. Stránka, kterou nikdo dva roky neotevřel, nemusí projít modernizací. Může zůstat jen pro čtení jako archiv, nebo se smazat. Převádět se vyplatí jen to, co musí zůstat upravitelné. Pro každou skupinu stránek tedy zvolte jednu ze tří cest: modernizovat, nechat jako archiv, odstranit.

Začněte tím, co je živé a důležité. Microsoft doporučuje seřadit stránky podle obchodní důležitosti a podle toho, jak často se upravují. Pak je seskupte podle složitosti. Převádět se tak dá po vlnách a co se naučíte v první vlně, využijete v dalších.

Nástroje existují, ale mají hranice:

• Transformace stránek přes PnP PowerShell je deterministický převod, který Microsoft popisuje jako hlavní cestu. Jeho základní postup ale pokrývá wiki stránky a stránky s webparty v knihovně Site Pages. Publishingové stránky, blogy, stránky mimo Site Pages, domovské stránky a zdroje ze SharePointu Server vyžadují samostatné, pokročilejší postupy. Engine je součást open-source knihovny PnP Framework a nemá podporu Microsoftu se SLA.
• SharePoint Page Modernization Agent je nový open-source agent s AI, který pomáhá u složitějších stránek – s vlastním HTML, obsahem Script Editoru nebo rozložením, které vyžaduje lidský úsudek. Je v preview a bez podpory Microsoftu, běží v nástrojích typu GitHub Copilot nebo Claude Code a spotřebovává tokeny jazykového modelu. Autoři sami doporučují každou vygenerovanou stránku porovnat s originálem. Obsah Script Editoru může skončit jen jako vysvětlující text, ne jako funkční náhrada.

Microsoft k tomu dodává větu, kterou stojí za to brát vážně: silně přizpůsobené stránky mohou vyžadovat nový návrh nebo ruční přestavbu. A upozorňuje, že vygenerovaná stránka může existovat, a přesto být prázdná nebo neúplná. Kontrola „otevřelo se to bez chyby“ proto nestačí.

Rozdělte práci mezi IT a vlastníky webů. Plánování, pořadí vln a příprava nástrojů patří centrálnímu IT. Obsah po převodu ale nejlépe zkontroluje ten, kdo ho používá – vlastník webu nebo oddělení. Vlnový postup umožní ověřit obsah, odkazy, oprávnění, webparty a rozložení dřív, než se pustíte do dalších stovek stránek.

Kalendář, který dává smysl

Do října 2028 zbývají necelé dva roky. Zní to jako dost, ale u intranetu s tisíci stránkami, kde každou vlnu musí zkontrolovat lidé z provozu, je to spíš akorát. Realistický plán:

Kdy	Co
do konce roku 2026	inventura: Assessment Tool + audit, seznam webů s vlastními skripty
do 1. 3. 2027	rozhodnout o klasických publishingových webech; od tohoto data nové nepůjde založit a migraci ze SharePointu Server je potřeba spojit s modernizací
2027	první vlny: nejdůležitější a nejčastěji upravované stránky, náhrada skriptů za moderní webparty nebo SPFx
1. pol. 2028	zbytek upravovaných stránek, archivace nebo odstranění nepoužívaných
1. 10. 2028	klasické stránky jsou jen pro čtení – v tu chvíli by v nich už nemělo zbýt nic, co je potřeba měnit

Co si z toho odnést

1. Obsah nezmizí, ale ztuhne. Od 1. 10. 2028 nepůjde upravit žádná klasická wiki, stránka s webparty, blog, publishingová ani vlastní ASPX stránka.
2. Publishingové weby končí dřív. Zakládat je a zapínat publikování nepůjde už od 1. 3. 2027 – to se týká hlavně migrací ze SharePointu Server.
3. Zjistěte, kde klasiku máte. Assessment Tool a audit v Purview dají dohromady seznam i informaci, co se reálně používá. Když nic nenajdou, nemusíte dělat nic.
4. Převádějte jen to, co musí zůstat živé. Zbytek nechte jako archiv nebo smažte. Nástroje pomůžou, ale bez lidské kontroly to nepůjde.

---

Modernizaci klasických webů a intranetů děláme jako součást kontroly prostředí a návrhu governance – od inventury přes rozhodnutí, co převést a co archivovat, až po moderní náhradu za stránky se skripty. Pokud máte SharePoint z doby před moderními stránkami nebo plánujete migraci ze SharePointu Server, ozvěte se nám.

Zdroje: Microsoft Message Center MC1464926 (31. 8. 2026), Microsoft Learn – Deprecation of Classic SharePoint Pages, Transform classic SharePoint pages to modern pages, Allow or prevent custom scripts, Microsoft 365 Assessment Tool, SharePoint Page Modernization Agent.