For most publishing teams, IT problems show up as a CMS that takes an age to load. A media library where nobody can find last month's photography. A newsletter that didn't go out on time and nobody noticed until a reader emailed in. The technology behind editorial operations tends to be invisible… right up until it isn't.

This article covers what publishers actually need from their IT infrastructure: what keeps a CMS performing well, where editorial workflows most commonly break down, how to manage digital assets without losing your mind, and what good IT support looks like for a publishing business.

We’ll discuss: 

• What IT infrastructure does a publishing CMS actually need?
• Why do CMS platforms slow down: and what is usually causing it?
• How should publishers manage digital assets and media libraries?
• What are the most common IT problems in editorial workflows?
• How do publishing teams collaborate securely on content across locations?
• How do you keep a publishing CMS secure and compliant?
• When does a publisher need dedicated IT support rather than a generalist?

Let’s start with your IT infrastructure.

What IT infrastructure does a publishing CMS actually need?

It depends on the platform and the scale of the operation: but a few things apply almost universally.

Servers sized for what you're actually running 

The most common publishing IT problem isn't a platform failure. It's infrastructure that was configured when the publication was smaller and never revisited. Traffic grows. The editorial team doubles. Integrations multiply. And the setup that worked fine two years ago starts to creak. 

For a small digital publisher on WordPress, well-configured managed cloud hosting is usually enough. For a larger magazine or news operation with hundreds of simultaneous editorial users and a complex tech stack, the requirements are considerably more demanding.

A database that's being looked after

Most CMS platforms are database-driven. As content libraries grow with thousands of articles, images, revisions, comments, database performance becomes a real factor in how responsive the editorial interface feels. Proper indexing, query optimisation and regular maintenance keep things running smoothly. Without it, performance degrades slowly and consistently, in a way that's easy to attribute to the wrong cause.

CDN configuration that's actually working

A Content Delivery Network distributes content delivery across servers closer to your readers, which reduces load on the origin server and improves page load times. For publishers serving audiences across the UK or internationally, a CDN isn't optional. Misconfigured or absent CDN setup is a surprisingly common finding: and one of the easier things to fix.

Backups that are tested, not just running

A publishing archive built over the years is a significant business asset. Automated backups stored separately from the primary environment are the baseline, but backups that have never been tested are not the same as backups that work. Disaster recovery planning should include a defined recovery time objective: how long can the publication be down before it becomes a serious business problem? The answer shapes what the backup and recovery setup needs to look like.

Why do CMS platforms slow down, and what is usually causing it?

The instinct when a CMS slows down is to blame the platform. However, that's rarely where the problem actually sits.

Plugin bloat

WordPress is particularly vulnerable to this. Editorial and development teams install plugins to solve specific problems, and over time the list grows: many of them conflicting, outdated, or no longer actively maintained. The cumulative performance impact can be significant. A plugin audit: what's installed, what's actually used, what can go, is often the quickest route to a meaningful speed improvement. WP Engine's research consistently shows that plugin management is one of the top factors in WordPress performance degradation.

Unoptimised images

A feature image uploaded at 6MB rather than 200KB, multiplied across thousands of articles, creates real load on the server and the reader's browser. Automatic image optimisation, at upload or through a CDN layer, is a straightforward fix. Most publishing operations don't have it configured.

A database that's never been cleaned

WordPress databases accumulate post revisions, transient data, spam entries and orphaned metadata over time. On a site with five years of content and no maintenance, this adds up. Regular automated database maintenance keeps query performance consistent as the content library grows.

Caching that isn't configured properly

Caching stores pre-rendered versions of pages so the server doesn't generate them fresh for every visitor. When it's working, it dramatically reduces server load: particularly during traffic spikes. When it's misconfigured, or hasn't been reviewed after a significant site change, pages are generated from scratch on every request. For a high-traffic publisher, that compounds quickly.

How should publishers manage digital assets and media libraries?

This is one of the most underinvested areas of publishing IT, and the one that causes the most daily friction as a publication scales.

publisher starts storing images, video, audio and documents across a mix of the CMS media library, shared drives and cloud storage. Each works well enough at first. Over time, assets fragment across platforms. Nobody is sure which version of an image is current. Licensing metadata lives in a spreadsheet that's two years out of date. A journalist on deadline can't find photography from a shoot six months ago.

This is a critical asset management problem.

Digital Asset Management (DAM) systems platforms like Bynder, Canto, or Brandfolder, provide a centralised, searchable repository for all media, with metadata tagging, version control, rights management and workflow integration. For publishers handling significant volumes of photography, video and branded assets, a DAM is what makes the media library usable at scale rather than a source of daily frustration.

The integration between a DAM and a CMS is worth particular attention. Most modern DAM platforms offer plugins that let editorial teams search and insert assets directly from within the CMS without switching between systems. On deadline, that matters.

For smaller publishers not yet at the scale where a dedicated DAM makes sense, the baseline is a properly structured cloud storage environment with consistent naming conventions and a clear folder taxonomy. It sounds unglamorous. It saves significant time.

Managing SaaS platforms, including DAM and CMS tools, across a publishing team is a discipline in itself, and one that benefits from a structured approach rather than ad hoc decisions made when someone needs access urgently.

What are the most common IT problems in editorial workflows?

Beyond CMS performance, publishing operations depend on a set of interconnected tools: editorial calendars, collaboration platforms, distribution systems, analytics dashboards, each of which has its own failure modes.

Integration failures between editorial tools

Most publishing operations run multiple platforms in parallel, connected by APIs and integrations. When an integration fails silently: not pushing content to a distribution channel, dropping a newsletter from the send queue, it often goes undetected until a reader or client notices. Monitoring integrations as actively as core infrastructure is an underappreciated discipline. It's also one that proactive managed IT support handles as standard, rather than waiting for someone to report a problem.

Access management across too many platforms

Editorial teams change constantly: staff join, freelancers are onboarded for a project, and contributors need temporary access. Managing who has access to what across a CMS, a DAM, a newsletter platform and a project management tool is operationally complex. Overly broad permissions are a security risk. Access that isn't removed when someone leaves is a more serious issue. A consistent onboarding and offboarding process applied across all platforms is basic: but frequently neglected.

Publishing pipelines that fail outside business hours. Scheduled publishing, automated content distribution and newsletter deployment all need to be reliable at the moment they're needed: which is often midnight, or early on a Saturday morning. A pipeline failure at that point reflects infrastructure that isn't being monitored proactively. 24/7 IT support with active monitoring catches these failures before they become reader-facing problems.

Version conflicts in collaborative editing

When multiple editors work on the same content simultaneously, version control matters. CMS platforms handle this with varying degrees of sophistication. Understanding how your platform manages concurrent editing and revision history, and whether it actually meets the needs of your editorial team, is worth reviewing before a conflict causes a problem.

How do publishing teams collaborate securely on content across locations?

Publishing is increasingly distributed. Editors, writers, photographers, designers and commercial teams may work across multiple offices, from home, or as freelancers with no fixed location. The IT setup needs to reflect that, and do so securely, given how much pre-publication content is genuinely sensitive.

Cloud-based editorial environments are now standard

Microsoft 365 and Google Workspace provide the document collaboration, communication and file sharing that distributed editorial teams need. The configuration of these environments: access controls, sharing permissions, external collaboration settings, matters considerably more than the choice between them.

Freelancers need controlled, time-limited access

Freelancers represent a specific IT challenge: they need meaningful access to editorial systems but operate outside the managed device environment that applies to full-time staff. Providing access through controlled, browser-based interfaces rather than VPN access to internal systems is one approach. Ensuring access is scoped to the work and removed when the project ends is another. Identity and Access Management controls make this systematic rather than something that gets remembered, or forgotten, on a case-by-case basis.

Pre-publication content needs protecting properly

Embargoed articles, unreleased features and commercially sensitive content need to be accessible to the people working on them and nobody else. That requires access controls that reflect the sensitivity of the content, not just the convenience of the team. A leaked exclusive is an IT failure with editorial and commercial consequences. Protecting sensitive client and content data is a discipline that applies as much to publishing as it does to any other creative business.

How do you keep a publishing CMS secure and compliant?

CMS platforms are among the most frequently targeted systems on the web. WordPress alone powers approximately 43% of all websites globally: which makes it a high-value target for automated attacks. The security of a publishing CMS deserves the same attention as any other business-critical system.

According to the DCMS Cyber Security Breaches Survey 2024, 50% of UK businesses experienced a cyber breach or attack in the past 12 months. For publishers running public-facing web infrastructure, the attack surface is broader than for businesses operating primarily behind internal systems: and the consequences of a successful attack are immediately visible to readers.

Keep everything updated

Outdated CMS software and plugins are the most common vector for web application attacks. Patch management, ensuring updates are applied promptly and tested before deployment, is the baseline. For publishers running complex environments with many integrations, managing updates carefully to avoid breaking changes requires a structured approach.

Use a Web Application Firewall

A WAF filters malicious traffic before it reaches the CMS application. Most managed hosting providers offer WAF capability. Configuring it correctly for a specific environment provides meaningful protection against SQL injection, cross-site scripting and brute force login attempts: the most common automated attacks on CMS platforms.

Enforce multi-factor authentication

MFA for all CMS users, not just administrators, significantly reduces the risk of account compromise through phishing. Given that 84% of cyber incidents involve phishing, according to the DCMS 2024 survey, this is one of the highest-impact security measures available. Two factors really are better than one, and for a publishing operation where a compromised editor account could mean a defaced or weaponised website, the stakes are real.

Take GDPR seriously for subscriber data

Publishers collecting subscriber data, running newsletters or using analytics platforms are processing personal data under UK GDPR. Cookie consent, data retention policies and the security of subscriber databases all fall within scope. The ICO's guidance for media organisations is the right starting point for understanding specific obligations. Getting this wrong carries regulatory risk, and reputational risk with an audience that chose to trust you with their data.

For a broader look at the cybersecurity risks that creative businesses face, The Cybersecurity Risks Marketing Agencies Overlook covers many of the same dynamics that apply to publishing operations.

When does a publisher need dedicated IT support rather than a generalist?

Earlier than most think.

Publishing technology stacks are genuinely complex

CMS platforms, DAM systems, newsletter tools, subscription management, analytics, advertising technology, and the integrations between them. A generalist IT provider who doesn't understand how a CMS caching layer interacts with a CDN, or why a newsletter deployment failure might be a DNS issue rather than a platform problem, will take longer to fix things that cost the business time and money.

The signs that a publishing operation has outgrown its current IT support are consistent: recurring problems that get fixed but come back, providers who need things explained, infrastructure decisions made reactively, and a growing sense that IT is holding the editorial and commercial teams back rather than keeping pace with them.

There's also the question of what outsourcing IT support actually looks like for a publishing business, not just a help desk to call when something breaks, but a partner that understands the operational context. Why midnight matters. Why a CMS outage during a traffic spike is different from one on a quiet Tuesday. Why the editorial team's tools deserve the same infrastructure thinking as the revenue-generating ones.

If your publishing operation is at that point, it's worth having the conversation before the next incident rather than after it.

At Lyon Tech, we work with publishing and PR businesses across London on IT infrastructure that keeps editorial operations reliable, secure and scalable. Get in touch with the team to talk through what that looks like in practice.