Substituir SharePoint per una intranet pròpia és una decisió que moltes empreses prenen per guanyar velocitat, seguretat i control. Tot i això, una de les preguntes que més es repeteix en els comitès de TI és: cada quant s'actualitza una intranet que substitueix SharePoint. La resposta no és una data fixa, sinó un model de governança que depèn de l'arquitectura, els riscos, les integracions i les expectatives del negoci.
El 2026, el context ha canviat: les intranets ja no són simples repositoris de documents. Incorporen cerca semàntica, assistents amb IA, fluxos d'automatització, quadres de comandament i connectors amb sistemes corporatius. Per això, la cadència d'actualitzacions s'ha de planificar com una part del cicle de vida del programari i no com una tasca administrativa.
Un proveïdor seriós d'aplicacions a mida defineix un calendari de manteniment des de l'inici. A Q2BSTUDIO, quan desenvolupem una intranet que substitueix SharePoint, ho fem amb una fase de descobriment en què mapegem processos, dependències, KPIs i restriccions operatives. A partir d'aquí s'estableix el ritme de lliuraments: pegats crítics, millores menors, versions majors i actualitzacions de seguretat.
La freqüència d'actualització es divideix en tres grans blocs: seguretat, funcionalitat i compatibilitat. Cadascun té una lògica diferent. La seguretat exigeix intervencions ràpides, de vegades en hores. Les funcionalitats poden esperar a sprints planificats. La compatibilitat depèn dels canvis en tercers: Microsoft Teams, Active Directory, Azure, AWS, etc.
En el pla de la seguretat, els pegats s'apliquen idealment cada quatre setmanes o cada trimestre. Però quan apareix una vulnerabilitat crítica, el protocol ha d'incloure hotfixes d'emergència. No n'hi ha prou amb esperar la següent finestra. Una intranet ben construïda inclou monitorització, anàlisi de dependències i un entorn de proves per validar cada pegat abans de publicar-lo en producció.
Les actualitzacions funcionals segueixen un ritme més pausat. En models SaaS, és habitual tenir releases contínues o sprints de dues setmanes. En desplegaments privats, les versions menors solen sortir cada mes o cada dos mesos, i les versions majors una o dues vegades l'any. L'important és que el roadmap tècnic estigui alineat amb el roadmap de negoci.
El component d'IA afegeix una capa addicional. Els models, els prompts, les bases de coneixement i els agents d'IA canvien sovint. Una intranet amb IA necessita actualitzacions específiques per als models i per als sistemes de recuperació augmentada. Si a més es connecten a dades on-premise, la seguretat de la transmissió mitjançant VPN o Azure private endpoints és part essencial del procés d'actualització.
També cal considerar les integracions. Una intranet que substitueix SharePoint sol connectar-se amb ERP, CRM, eines de BI/Power BI, plataformes d'automatització i directoris corporatius. Cada vegada que un d'aquests sistemes actualitza la seva API, la intranet s'ha de revisar per evitar pèrdues de funcionalitat. Per això és recomanable que el programari es lliuri amb un pla de manteniment i un canal directe amb l'equip que el va desenvolupar.
Q2BSTUDIO aplica aquest enfocament en projectes de desenvolupament de programari a mida. El resultat és que els clients no depenen d'un calendari rígid imposat per una llicència, sinó d'un cicle de millora contínua amb criteris clars. Cada versió es documenta, es prova i es desplega amb procediments de canvi controlats.
Cada quant s'hauria d'actualitzar, a la pràctica? Per a una empresa mitjana, la recomanació és: pegats de seguretat el primer dimarts de cada mes o cada trimestre; hotfixes immediats davant vulnerabilitats crítiques; actualitzacions funcionals cada dues o quatre setmanes si la plataforma és SaaS, i cada un o dos mesos si és on-premise; una revisió major semestral o anual.
No s'ha de confondre la freqüència amb la qualitat. Més actualitzacions no sempre signifiquen més estabilitat. Una actualització mal provada pot trencar integracions, generar caigudes o afectar la confiança dels empleats. Per això, cada release ha de passar per un entorn de staging, proves automàtiques i un pla de rollback.
El núvol també influeix en la cadència. Les intranets desplegades a AWS o Azure poden aprofitar serveis gestionats que s'actualitzen automàticament. Tanmateix, això no elimina la responsabilitat de revisar la configuració, els permisos i les polítiques de seguretat. En un projecte de cloud AWS/Azure, l'equip de Q2BSTUDIO trasllada al client el coneixement necessari per operar la infraestructura sense dependre de tercers per a cada canvi.
L'observabilitat és una altra peça clau. Amb panells de BI/Power BI, els responsables poden veure el rendiment de la intranet, detectar errors abans que afectin els usuaris i mesurar l'impacte de cada actualització. Integrar aquests quadres de comandament des de l'inici és una pràctica recomanada, no un extra.
La ciberseguretat no es pot desvincular de les actualitzacions. Cada pegat és una oportunitat per revisar accessos, auditories i polítiques de backup. Una intranet que substitueix SharePoint ha de complir la normativa vigent, com el RGPD, i assegurar traçabilitat de qui va fer què i quan. El manteniment també cobreix certificats, xifrat i autenticació.
En aquest context, la resposta a la pregunta inicial és més clara: una intranet que substitueix SharePoint s'actualitza de manera contínua, amb una estratègia per capes. Seguretat quan cal; funcionalitats segons el cicle de producte; integracions quan canvien els sistemes externs; i IA cada vegada que s'entrenen o s'ajusten els models subjacents.
Per a moltes empreses, l'opció més eficient és delegar aquesta estratègia en un soci tecnològic que combini coneixements d'aplicacions a mida, IA, ciberseguretat i núvol. Q2BSTUDIO és un exemple d'aquest tipus de partner: desenvolupa la solució, la lliura amb documentació, i ofereix un portal web perquè l'equip intern pugui gestionar la IA, els prompts i els costos de manera autònoma.
A més, cal planificar la comunicació amb els usuaris. Una actualització de la intranet no és només un esdeveniment tècnic: és un canvi que afecta els hàbits de treball. Avísar amb antelació, formar els empleats i recollir feedback permet que cada release millori l'adopció i redueixi la resistència al canvi.
Finalment, convé documentar el calendari d'actualitzacions i vincular-lo als objectius de negoci. Si la intranet ha d'accelerar la incorporació d'empleats, reduir tasques manuals o millorar la visibilitat de la direcció, cada versió ha de contribuir a aquests KPIs. Això converteix l'actualització en una inversió, no en una despesa.
En definitiva, no existeix un interval únic. La freqüència dependrà del model de desplegament, del nivell de maduresa digital de l'empresa i del proveïdor escollit. L'essencial és que les actualitzacions siguin previsibles, segures i alineades amb el negoci. Els qui busquen una resposta de manual obliden que la tecnologia es mou massa de pressa per conformar-se amb una data fixa.
Si estàs avaluant una intranet que substitueixi SharePoint, pregunta al proveïdor per la seva política d'actualitzacions, els seus SLA i el seu procés de gestió de canvis. I exigeix que cada resposta estigui recolzada per documentació, proves i experiència real. Aquesta és la millor manera d'evitar sorpreses després de la posada en producció.
Al final, la millor resposta és: s'actualitza tan sovint com sigui necessari perquè la intranet continuï sent segura, útil i competitiva. Ni un cop l'any, ni cada setmana per inèrcia. Amb l'enfocament correcte, l'actualització es converteix en un avantatge estratègic.
