You feel it every time a hosting question hits your inbox mid-redesign: the agency needs access, IT wants controls, the timeline wants speed, and no one is sure who’s actually allowed to say yes.
During a WordPress redesign, marketing should own hosting business requirements and tradeoffs, IT should own risk and access controls, and a named hosting owner must hold final environment and vendor decisions.
This isn’t a technical problem. It’s a decision-rights problem. Until you decide who owns which hosting calls, every cutover, plugin install, or environment tweak becomes a miniature governance crisis.
If you haven’t already defined the hosting decisions themselves, treat “WordPress Hosting During a Redesign: Governance Decisions You Must Lock In Before You Touch the Theme” as prerequisite reading; this article assumes that checklist and focuses on who decides, not what to decide.
1. The Real Problem: Hosting Decisions No One Feels Entitled to Make
There’s a specific moment in many redesigns that exposes the ownership gap.
The agency pings your marketing director: “We need database access to run the migration.” Marketing loops in IT. IT asks, “Who approved this? What’s the rollback plan? Who’s on the hook if it goes down?” Silence. The launch window slips because no one feels entitled to make the hosting call.
We often see three patterns behind that silence:
- The person who signed the redesign budget is not the same person who owns uptime and security risk.
- The agency assumes “we’ll sort it” until they hit an access or policy boundary.
- IT assumes “they’ll never touch production without us” until they discover a live change in a change-log after the fact.
The result is a familiar consequence chain:
- Redesign timelines slip for avoidable approvals.
- Risky production changes get rushed without rollback plans.
- Trust erodes between marketing, IT, and the agency.
- The website stays in a low-maturity, reactive mode long after launch.
Unclear hosting ownership is not a minor process wrinkle; it’s a leading indicator of weak website governance.
Your job as the business or marketing leader is not to answer every technical question, but to make one structural decision: who owns which WordPress hosting decisions during and after the redesign.
2. The Decision Moment: Which Hosting Calls Actually Matter During a Redesign?
To untangle ownership, you need to know the specific calls that create friction. During audits and redesign planning, we see the same hosting decisions surface over and over.
Environment and architecture decisions
These choices shape how safe and flexible your redesign will be:
- Where does staging live? Same host as production, separate account, or separate provider?
- Who can create, clone, or destroy environments? (e.g., extra staging sites for campaigns.)
- Is this the moment to upgrade hosting? Move off shared hosting, change providers, or adjust PHP/MySQL versions.
These decisions change cost, complexity, and risk, so they rarely belong to a single team acting alone.
Access and permissions
Mid-project is when access chaos surfaces:
- Who can grant the agency SFTP/SSH/database access—and under what conditions?
- Who can add and remove admin-level WordPress users?
- Who controls API keys, secrets, and environment variables linked to other systems?
If you don’t pre-assign ownership, you get emergency tickets to IT and late-night security anxieties.
Backups, rollback, and cutover
This is where outages and finger-pointing usually appear:
- Who defines backup frequency and retention during the build and at launch?
- Who triggers a manual backup before each major deployment?
- Who has authority to call a rollback if the new site misbehaves?
- Who approves the exact cutover window (date, time, freeze period)?
The hidden failure mode here is simple: no one wants to own rollback authority, so everyone hesitates—precisely when speed matters most.
Performance, capacity, and uptime
Even if you keep your current host, someone has to decide:
- Acceptable performance baselines during the redesign.
- Whether to scale up resources ahead of a big campaign launch.
- Maintenance windows, uptime expectations, and response paths if the site slows or fails.
Each call is part technical, part business. That’s why “IT will handle it” or “the agency will handle it” is never the full answer.
3. Three Players, Conflicting Defaults: Agency vs. IT vs. Marketing
Different groups walk into a redesign with their own silent assumptions about hosting. Those assumptions collide the first time someone needs a production change.
Marketing: accountable for outcomes, underpowered on rights
Marketing leaders usually:
- Own the budget and revenue goals tied to the site.
- Feel the pain of missed launch dates and broken funnels first.
- Assume hosting is a “technical detail” others will sort out.
Blind spots:
- They underestimate how many redesign decisions are actually hosting decisions in disguise.
- They haven’t defined what risk level they’re willing to accept for uptime, security, and performance.
- They rarely formalize who can say “yes” or “no” when risk and speed collide.
Yet marketing often ends up blamed when the site is down or conversions drop after launch—even if they never touched a hosting panel.
IT: accountable for risk, skeptical of one-off projects
IT teams usually:
- Own infrastructure risk (security, uptime, access control).
- Default to caution about outside vendors touching production.
- Prefer standards over one-off exceptions.
Blind spots:
- They may not see how delays or rigid rules affect campaigns and revenue.
- They can get pulled into tactical WordPress tasks they don’t want and aren’t staffed for.
- They may treat the agency as just another vendor request, not as a semi-embedded extension of the team for the redesign window.
So IT can become the perceived “blocker,” even when they’re just protecting the business from an ungoverned cutover plan.
The agency: responsible for delivery, miscast as the owner
Your redesign agency usually:
- Owns design and implementation for the new site.
- Feels pressure to hit launch dates and demonstrate progress.
- Assumes someone will give them what they need from the host.
Blind spots:
- They may overestimate the client’s internal hosting maturity.
- They sometimes accept de facto ownership of hosting by being the only ones willing to make a call in a crisis.
- They rarely want to be accountable for long-term uptime and risk, but they might not say that clearly enough.
As a rule, agencies should rarely be the final accountable party for production hosting risk. They should be responsible for the changes they ship, but they shouldn’t become your invisible infrastructure department.
The fix is not “pick a hero” but “define a map.” That’s where a simple RACI comes in.
4. A Simple RACI Map for WordPress Hosting in a Redesign
You don’t need a consulting binder to clarify ownership. You need one page that names who is Responsible, Accountable, Consulted, and Informed for each key hosting decision.
Below is a compact RACI you can adapt. Assume three roles:
- Marketing lead (M) – your redesign sponsor.
- IT lead (IT) – whoever owns infrastructure/security.
- Agency lead (A) – your primary account/technical lead at the agency.
You may also have a fourth role: Hosting owner (H)—this might be IT, a DevOps function, or a managed hosting partner.
Example RACI snapshot
| Decision Area | Responsible (R) | Accountable (A) | Consulted (C) | Informed (I) |
|---|---|---|---|---|
| Choose hosting provider / plan | IT or H | M | IT, A | Exec sponsor |
| Create/maintain staging and dev environments | H or A | H | IT, A | M |
| Grant and revoke environment access | H | IT | M, A | Security/compliance |
| Define backup and rollback policy | H | IT | M, A | Exec sponsor |
| Approve launch window and change freeze | M | M | IT, A | Support teams |
| Trigger cutover and, if needed, rollback | H or A | H | IT, M | Exec sponsor |
| Post-launch performance and uptime targets | IT | M | H, A | Exec sponsor |
This is not a law. It’s a conversation starter. But there are a few ground rules:
- Every row must have exactly one “A.” If more than one person is accountable, no one is.
- Marketing must be “A” for business-impact tradeoffs. Launch timing, acceptable risk windows, and budget boundaries belong here.
- IT (or H) must be “A” for technical risk and access control. No agency should be accountable for your long-term infrastructure risk.
- The agency is usually “R”, not “A”, for changes they implement. They do the work but within a governance frame you own.
If you adopt only one practice from this article, adopt this one: put this RACI in front of all three players before the redesign moves into build.
5. Using Maintenance Maturity to Decide Who Should Be Accountable
The right RACI depends on how mature your website operations are. A small team on shared hosting doesn’t need the same structure as an enterprise with a dedicated DevOps group.
Think in terms of Maintenance Maturity—how your organization moves from reactive fixes to proactive, recurring website stewardship.
Low maturity: reactive, project-by-project
Signs:
- Hosting was picked years ago and rarely revisited.
- There’s no regular review of performance, security, or backups.
- Redesigns are treated as rare, disruptive events.
Ownership implications:
- Marketing is often the only visible owner, by virtue of budget.
- IT may be lightly involved or entirely absent.
- Agencies end up making one-off hosting calls just to keep the project alive.
Here, your goal is not to build an enterprise governance machine. It’s to:
- Name a single hosting owner (for now) who is accountable for environments, access, and basic risk decisions.
- Get that owner to agree to a lightweight RACI for this redesign.
Often that owner is an IT generalist or a managed host. If you don’t have either, you are asking a marketing leader to quietly carry infrastructure risk—which is risky for the business and unfair to them.
Mid maturity: shared but fragile ownership
Signs:
- IT is involved and has opinions on security and uptime.
- Marketing has KPIs tied to digital performance.
- Hosting changes trigger cross-team email threads, but there’s no standard process.
Ownership implications:
- Accountability is split: IT feels responsible when things break; marketing feels responsible when revenue is hit.
- Disagreements go up a level to an exec who lacks the detail to decide well.
Here the goal is to stabilize accountability across redesigns:
- Make marketing accountable for business tradeoffs (timelines, acceptable risk windows, budget).
- Make IT (or a named hosting owner) accountable for technical risk (access, backups, security posture).
- Keep the agency squarely in the Responsible column for implementation.
Your Maintenance Maturity improves when these lanes stay consistent, even as people or agencies change.
High maturity: standing website governance
Signs:
- There’s a standing website steering group or governance committee.
- Hosting, security, SEO, and UX get reviewed on a rhythm, not only in redesigns.
- Change management and incident response are documented and practiced.
Ownership implications:
- A specific function (internal or outsourced) holds long-term accountability for hosting.
- Redesigns plug into existing governance, rather than improvising new rules.
At this level, your RACI barely changes between projects. The hosting owner is a role, not a person, and the organization understands how to work with them.
Wherever you sit on this maturity spectrum, your redesign is a chance to move one step up, not reset to zero.
6. How to Socialize and Lock In Your Hosting Ownership Map
You don’t need a six-month governance project to make progress. You need a clear artifact and a short, pointed conversation.
Step 1: Draft the RACI with your best guess
Start with:
- The decision areas listed earlier.
- A simple table like the one above.
- Your best guess at R, A, C, and I for each cell.
Treat this as a proposal, not a decree.
Step 2: Run a 45-minute decision-rights review
Invite:
- Marketing lead for the redesign.
- IT/infrastructure lead.
- Agency account/technical lead.
- Whoever ultimately signs off on risk (if different).
Walk through the table row by row. Where you see disagreement, ask:
- “Who is willing to be accountable if this goes wrong?”
- “Who has the information to make this call quickly?”
- “Who will be blamed if this fails today? Does the RACI match that reality?”
This can feel blunt, but it surfaces the real politics and expectations so you can adjust the map accordingly.
Step 3: Embed the RACI in working documents
Once agreed, put the RACI in:
- The redesign Statement of Work and any change orders.
- Your internal runbooks for deployments, incidents, and access requests.
- The agency’s ways-of-working documentation for your account.
Spell out a few critical guardrails, such as:
- No production changes without a named accountable approver.
- No new admin accounts without hosting owner sign-off.
- Rollback authority rests with X role under Y conditions.
Step 4: Update job descriptions and expectations
If someone is the hosting owner, their job description and performance expectations should say so. Otherwise, you’re counting on personal goodwill instead of durable governance.
At minimum, align on:
- What “good” looks like for hosting (uptime, responsiveness, risk posture).
- How the hosting owner is involved in future redesigns or feature launches.
Step 5: Revisit the map after launch
About 4–8 weeks after launch, run a short retrospective:
- Where did hosting decisions stall?
- Where did the RACI keep things moving?
- What escalations felt messy or unclear?
Adjust the map and keep it as your baseline for the next project. The same RACI can and should continue as part of ongoing maintenance governance, not just a one-off artifact.
If, as you go through this, you realize the biggest gap is not clarity but capability—no one actually wants or is able to be the hosting owner—that’s your signal to bring in outside help.
7. When You Need a Hosting Partner to Be the Adult in the Room
Some organizations will never have a stable, internal hosting owner. The work is too specialized, the IT team is stretched thin, or marketing is tired of mediating technical disputes.
Signs you should consider a fully managed hosting partner as your hosting owner:
- IT is overloaded and treats WordPress as a low-priority outlier.
- Marketing is making hosting decisions by default because they’re the only ones engaged.
- The agency keeps getting pulled into infrastructure questions they aren’t paid or staffed to answer long term.
- Incidents are handled ad hoc—whoever notices the issue first becomes the temporary owner.
In support work, we’ve noticed that the healthiest redesigns have a fourth chair at the table: a hosting partner whose job is to run environments safely, not design or approve campaigns.
A managed WordPress hosting provider can:
- Own the environment lifecycle—dev, staging, and production—so the agency can build without holding the keys to everything.
- Apply consistent access controls and backup policies that survive personnel changes.
- Provide clear escalation paths during cutovers and incidents, instead of scrambling to find “who owns this server.”
- Participate in your RACI as the Hosting owner (H), giving IT and marketing a stable, expert counterpart.
If you know you need a named, experienced owner for environments, access, and risk beyond this redesign, it’s worth looking at a partner whose entire engagement is built around that role. Best Website’s WordPress Hosting (Fully Managed) service is designed to operationalize this: not just to run servers, but to sit in the governance lane your RACI creates.
8. Decision-Oriented Wrap-Up: One Clear Owner, or Guaranteed Drift
You don’t need another meeting about “collaboration” between marketing, IT, and your agency. You need one concrete decision: who is the hosting owner, and what rights do they hold during this redesign and after launch?
If you let that question linger:
- Redesign launches will continue to slip for preventable approval snarls.
- Risky production changes will be made without clear rollback authority.
- The site will stay in a low-maturity, reactive mode where every issue becomes a fire drill.
If you answer it now and capture a one-page hosting ownership map, your redesign stops being a tug-of-war and becomes a governed, repeatable process. You move from “the agency will sort it” to “this is how our website works around here.”
From here, there are two concrete moves:
- Draft and ratify your RACI. Use this article as a template, and, if you need broader redesign governance context, skim the Website Redesign articles hub to see how hosting ownership connects to SEO, content, and sequencing decisions.
- Decide whether hosting ownership should live inside your org or with a specialist. If no one internally has both the time and appetite to own environments, risk, and cutovers, it’s time to give that role to a partner whose charter is exactly that.
To apply this decision to your own website, discuss the next step with our team.