On this page
Modernizing a website often begins with frustration about maintenance on the old platform. The new stack can make that work more predictable, but it does not make it disappear. Every website relies on software, services and people. Agreeing who does what before launch is one of the most valuable outcomes of a modernization project.
Map the components
List each component of the new website and who is responsible for it:
- Application code: the front end and any server functions.
- Dependencies: frameworks and libraries the code relies on.
- Content management: the CMS, its users and its configuration.
- Hosting and infrastructure: servers or platforms, environments and deployments.
- Domain and DNS: registrar account, records and renewals.
- Third-party services: forms, CRM, email delivery, analytics, booking and payments.
- Content: pages, articles, images and their accuracy.
Dependency updates
Modern frameworks and libraries release updates regularly, including security fixes. Agree how often updates are reviewed, how they are tested, ideally through automated builds and checks on a staging environment, and who approves deployment. Define how urgent updates are handled outside the usual cycle.
Hosting and monitoring
Decide who watches uptime, error rates and certificate renewals, and where alerts are sent. Confirm backup arrangements and how often restores are tested. If the hosting platform manages some of this, document what it covers and what it does not.
Access management
Keep an up-to-date list of who can access each account. Review it when people join or leave and when supplier relationships change. Use individual accounts and multi-factor authentication where available.
Content ownership
Assign owners to key sections of the site so information stays accurate. Schedule periodic reviews for content that can go out of date, such as service details, team pages and contact information.
Integrations
Third-party services change their APIs, pricing and terms over time. Someone should own each integration and be notified of changes from the provider. Test critical flows, such as enquiry forms, after any change on either side.
Security reviews
Security is ongoing work. Periodic reviews of dependencies, access, configuration and third-party services help identify issues early. No architecture is immune to vulnerabilities; the goal is a manageable process for finding and fixing them promptly.
Documentation and handover
At launch, the project should leave behind documentation covering architecture, environments, deployment steps, integrations and contacts. Editors need short task guides. Whoever maintains the site later will rely on this.
Choosing a support model
Some organisations handle maintenance in-house, some use a support agreement, and some combine both. Whichever model you choose, write down the scope of work, expected response for different types of issues and how changes are requested and prioritised.
Budget for the long term
Ongoing maintenance has a cost, whether in staff time or supplier fees. Including it in planning from the start avoids the situation many older websites end up in, where updates were postponed until moving became the only practical option.
A healthier cycle
A modernization that ends with clear responsibilities sets the website up for steady improvement instead of periodic crisis. That clarity is as much a part of the result as the new design or technology.
Turn this topic into a project plan
Use these supporting guides to prepare the details for your modernization discussion.
Put this into practice
Planning a move like this?
See how a scoped website modernization project handles content, URLs, integrations and launch.