European Digital Transformation: Innovation, Interoperability and Modernisation

Digital innovation as a maintenance discipline

Innovation in the public and academic sectors is rarely about being first. It is about raising the ceiling of what an organisation can do routinely. A university department that can publish a multilingual, accessible, permanently addressable research output in an afternoon is more innovative, in any meaningful sense, than one that commissions a spectacular microsite every three years and abandons it.

This reframing matters because it changes what gets funded. Under the spectacle model, money goes to visible new surfaces. Under the capability model, money goes to content models, identifier schemes, editorial tooling and migration capacity — the things that make the next ten changes cheap. The organisations we find most convincing measure themselves on time-to-publish and time-to-migrate, not on redesign frequency.

It also changes procurement. If the goal is capability, the contract should specify export formats, data ownership, identifier stability and exit assistance as functional requirements, alongside the design brief. The digital transformation and WordPress analysis makes a similar case from the implementation side.

Interoperability: between organisations, and between decades

European interoperability thinking is usually framed across four layers: legal, organisational, semantic and technical. All four apply to a website. Legal interoperability determines whether content can be reused and under what licence. Organisational interoperability determines whether two departments can publish into the same structures. Semantic interoperability determines whether a "publication" means the same thing in two systems. Technical interoperability determines whether the bytes move.

The most common failure is semantic and internal. Two faculties model a research output differently, so a shared index is impossible without manual reconciliation. Fixing this is unglamorous work: agree on entity definitions, agree on controlled vocabularies, publish them, and enforce them in the editing interface rather than in a style guide nobody reads.

Then there is interoperability across time — whether the 2014 site can be understood by the 2026 system. Stable identifiers are the whole answer. If a URL is treated as a permanent public reference rather than a routing detail, migrations become survivable. Our article on interoperability and open standards turns this into concrete tests.

Open standards and technological neutrality

The case for open standards is economic before it is ideological. A standard with multiple independent implementations creates a competitive supplier market; a proprietary format creates a single supplier with pricing power and an implicit veto over your future.

For web publishing the essential set is small and stable: HTML for documents, CSS for presentation, HTTP status codes and redirects for identity, JSON for interchange, schema.org for meaning, WCAG for accessibility, and open media formats for images and video. An organisation that stays within this set can change vendor, framework or CMS without renegotiating its content.

Technological neutrality does not mean refusing to choose. It means choosing in a way that can be reversed. In practice: prefer self-hostable software, insist on documented exports, keep content in the CMS rather than in the theme, and test the export path before it is needed. The portability checklist and the vendor lock-in prevention guide are practical instruments for this.

AI adoption without new dependencies

AI arrived in public-sector and academic web work through the side door: staff used assistants to draft copy, then to build prototypes, and eventually a generated site was in production. This is not a scandal — it is a genuine productivity gain — but it creates an estate of sites that nobody formally commissioned and whose maintenance path is unclear.

A sensible policy accepts the tools and constrains the outputs. Generated code is welcome; it must land in version control. Generated prototypes are welcome; they must be re-platformed onto the standard stack before they carry official content. Generated content is welcome; it must be reviewed and attributed by a named person. Under those three rules, AI adoption increases capacity without increasing dependency.

Institutions that do this well tend to treat AI builders as a design phase rather than a hosting decision. The relevant background reading is our review of AI website builders, the no-code versus code comparison and the quality checklist for AI-generated websites.

Cloud technologies and the portability test

Cloud adoption gave institutions elasticity and removed a great deal of hardware drudgery. It also introduced a subtler form of coupling: managed services whose equivalents do not exist elsewhere. A deployment that depends on one provider's function runtime, identity service and proprietary datastore is portable only in theory.

The useful discipline is a portability test rather than a cloud strategy document. Could this workload be redeployed with a different provider in a defined number of days, using documented steps, without data loss? If the answer is yes, the managed services are a convenience. If it is no, they are a dependency and should be recorded as risk.

For websites specifically, portability is easy to preserve: a standard runtime, a documented database, object storage for media, and infrastructure described as code. Hosting considerations and environment parity are covered in the hosting documentation, backups and recovery in the backup and recovery guide, and transport security in the SSL and HTTPS guide.

Website modernisation: how legacy estates actually move

Most organisations do not have one legacy website. They have a main site, a handful of project sites from expired funding rounds, a conference site nobody can log into, and an archive of documents referenced by external parties. Modernisation means deciding, per property, between four outcomes.

Keep and migrate

The property is active and valuable. Move it to the standard platform with full preservation of URLs, metadata and assets, as described in our migration guide.

Freeze and preserve

The property is finished but must remain citable — a completed project, a past conference, a closed journal issue. Convert it to static files, keep the URLs, and host it cheaply and indefinitely. This is the least appreciated and most valuable option, and the static versus dynamic analysis helps decide when it applies.

Consolidate

The property duplicates content that belongs on the main site. Merge it, redirect every URL to its specific new location, and retire the domain only after the redirects have been live long enough for search engines to consolidate signals.

Retire deliberately

The property has no ongoing value. Archive a copy, publish a short notice at the root, and keep redirects for the handful of URLs that receive external traffic. Deleting a domain outright breaks other people's citations and should be a last resort.

Sequencing a modernisation programme

The sequence that works in practice is: inventory, triage, standardise, migrate, verify, maintain. Inventory means a crawl of everything the organisation owns, including forgotten subdomains. Triage applies the four outcomes above. Standardise means agreeing the content model, the identifier scheme and the accessibility baseline before any migration begins, so that each move lands on the same target.

Migration then proceeds property by property, smallest first, so the team learns on low-risk material. Verification uses the same evidence for every property: URL parity, metadata parity, asset parity, performance and accessibility. Maintenance means someone is named, funded and expected to run the same checks annually.

Detailed procedures for the migration step are documented in the conversion guide library, with the specific approach for framework-based sites in the single-page application conversion guide and content mapping in the CMS content migration guide. Where multilingual obligations exist, see the multilingual setup documentation.

Measuring whether transformation happened

Four measures tell you more than any strategy document. Time-to-publish: how long from approved text to live page. Time-to-migrate: how long to move one property to the standard platform. Link integrity: percentage of historical URLs that still resolve. Accessibility conformance: percentage of templates meeting the baseline. All four are cheap to collect and hard to fake.

Continue with our digital preservation article, the SEO continuity discussion, the Core Web Vitals article, or the practical learning resources library. Platform-level choices are compared in the AI builders review and common questions answered in the FAQ.