Should Your Redesign Include a New Support Model? How to Bake Ongoing Ownership Into a Rebuild

You’re planning a serious website redesign. The proposals look good, the designs are promising—and all of them bury post-launch support in a single line like “includes 60 days of maintenance.”

If you’re rebuilding a serious business website, you should only approve a redesign plan that also defines who owns the site after launch, how issues are handled, and what ‘healthy’ looks like month to month.

Everything else is an expensive reset button on the same underlying problem: no operating model for how the site is owned, maintained, and improved.

A redesign that doesn’t upgrade your support model is just a more expensive way to end up back in the same mess.

This article is about that decision: whether you keep your existing support setup and “bolt on” a new site, or use the redesign to define a new operating model for ownership, SLAs, and Maintenance Maturity.

If you haven’t already thought about governance risks in your redesign, you may want to start with the prerequisite piece on governance pitfalls that make new builds turn into support headaches and then come back here to design the model that prevents them.

---

1. The real decision hiding inside your redesign brief

Most redesign briefs ask:

• What should the new site look like?
• Which tech stack / CMS should we use?
• What’s in scope for launch?

The missing question:

What support model will own this new site once the launch team disappears?

That support model is not just “which vendor handles tickets.” It’s:

• Who can request changes (and how)?
• Who decides priorities when there’s more work than capacity?
• How fast must issues be fixed for the business to be comfortable?
• Who is accountable for keeping content accurate and on-brand?
• How does the site actually improve over time instead of drifting?

When those questions are left implicit, the pattern is painfully consistent:

• Big launch, lots of attention, a burst of post-launch bug fixes.
• Then the ticket queue goes quiet for a while.
• Six months later, people are working around the website again, updates feel slow or risky, and leadership is asking why the expensive redesign “already feels out of date.”

The hidden failure mode: a new site launched into the same vague, under-resourced support model is more dangerous than keeping the old site with clear ownership. At least with the old site, you know where the cracks are.

Your redesign brief is not just a creative document; it’s your one clean chance in the next few years to reset how the website is actually run.

---

2. When a redesign does – and doesn’t – justify a new support model

Before you rewrite your RFP, check whether you actually need a new support model or just a tune-up.

First distinction: relationship vs. model

Teams often conflate three different things:

• Support relationship – which vendor or team handles your tickets.
• Support model – the rules: SLAs, cadence, decision rights, what’s in scope.
• Project scope – what’s included in the redesign build and launch.

You can:

• Change vendors but keep a weak model (new agency, same chaos).
• Improve the model without changing vendor (better SLAs, clearer ownership).
• Redesign the site without touching the model (new UX, old operating pain).

You’re aiming for: new site, right-sized support model, and a clear ownership map.

When you can probably keep your current model

Your existing support setup may be fine if:

• The redesign is incremental (visual refresh, minor UX improvements).
• Ticket response and resolution times already match your business tolerance.
• There’s a clear owner for backlog grooming and release planning.
• Content stays accurate and on-brand today without heroic effort.
• Nobody is surprised by who approves changes or how they get into production.

In this case, your redesign RFP should still reference your current model, but you may only need modest adjustments (e.g., short-term extra capacity after launch).

When the redesign should trigger a new model

You should treat the support model as in scope for the redesign if any of these are true:

• The new site will handle more revenue-critical flows (ecommerce, lead routing, portals).
• You’re adding more complex integrations (CRM, marketing automation, product data).
• You’re moving to a more flexible CMS or component system that marketing can touch directly.
• Leadership expectations are changing (“no more embarrassing issues,” “faster campaigns,” “better compliance”).
• Today’s support is already slow, unclear, or reactive.

A practical rule of thumb:

If the redesign changes how often and how deeply you’ll touch the site, your support model has to change to match that pattern.

---

3. A simple test: is your current support model fit for the site you’re designing?

Before you finalize scope, run your current model through this Fit-for-Future Test.

Answer these questions honestly:

1. Change Volume

   • In the new world, how many changes per month will you want to make (pages, components, integrations, campaigns)?
   • Does your current model comfortably handle that volume today, or is it already creaking?

2. Revenue Dependency

   • Which flows on the new site will be directly tied to revenue or critical leads?
   • Are your current SLAs strong enough that you’d be comfortable if those flows broke on a Friday afternoon?

3. Compliance & Risk

   • Will your new site expand into regulated content, accessibility exposure, or sensitive data handling?
   • Do you have a defined process for urgent compliance changes (who can escalate, how fast they’re deployed, who signs off)?

4. Internal Skills & Bandwidth

   • Are you investing in your internal team’s skills to match the new build (content design, components, analytics, QA)?
   • Or is everyone assuming “IT will just handle it” even though IT doesn’t own marketing priorities or UX?

5. Backlog Reality Check

   • Look at your current ticket backlog. Is it:
     • Short, prioritized, and regularly cleared, or
     • A graveyard of “someday” requests and half-finished ideas?

If your honest answers don’t line up with the ambition of the new site, your support model is not fit for the site you’re designing.

We often see redesign briefs that are bold about launch goals but silent on these questions. That’s how you end up with a shiny new site and the same old slow-motion backlog.

---

4. What to bake into your redesign RFP about post-launch ownership

“Includes 30–90 days of post-launch support” is not a support model. It’s a warranty window.

Your redesign RFP should specify the operating model for after that window closes.

Here’s what to make explicit.

1. Roles and decision rights

Spell out who owns what, both internally and externally.

• Product owner / website owner (often marketing, operations, or digital lead) – prioritizes the backlog, owns the roadmap, and is accountable for business outcomes.
• Support partner (internal team, external vendor, or hybrid) – implements changes, maintains infrastructure, and advises on tradeoffs.
• IT / security – controls hosting, security posture, and technical risk thresholds.
• Legal / compliance – defines content constraints and review requirements.

In the RFP, ask vendors to respond to:

• How they prefer to work with an internal website owner.
• Which decisions they expect to make vs. which stay with you.
• How they handle conflicts between marketing urgency and technical risk.

2. What “in-scope” support includes

Be explicit about categories of work and who handles them. For example:

• Break/fix: site down, critical errors, broken forms.
• Small changes: copy tweaks, image swaps, minor layout changes.
• New content: new pages, landing pages, resource hubs.
• Structural changes: new templates, new components, navigation changes.
• Integrations: CRM updates, tracking changes, marketing automation.
• Quality / risk: accessibility fixes, performance tuning, SEO hygiene.

Your RFP should ask:

• Which of these are included in ongoing support vs. treated as new projects.
• How many hours or story points per month are assumed.
• How scope creep is handled without endless change orders.

If you already know you’ll need regular performance or SEO tuning, pair this article with your thinking from the piece on when ongoing performance tuning needs its own support model so you don’t hide that work inside vague “maintenance.”

3. SLAs and release cadence

Define how fast things move and when.

• Response times for different ticket severities.
• Resolution targets (even if they’re “best effort”) for:
  • Critical outages.
  • High-impact bugs.
  • Routine updates.
• Release cadence:
  • Are changes batched into weekly releases?
  • Do critical fixes ship immediately?
  • How is regression testing handled?

Ask vendors to detail:

• Their standard release windows.
• Their regression testing approach before each deploy.
• How they communicate risks when timelines are tight.

4. Escalation paths

Invisible until you need them, but critical.

Your RFP should clarify:

• Who can declare a “critical incident.”
• How escalations flow (support → tech lead → leadership).
• When leadership is notified (e.g., revenue-impacting incidents).

5. Success measures

Beyond “site is live,” what does good look like in month 3, 6, 12?

Consider:

• Mean time to resolve critical tickets.
• Number of regressions introduced by releases.
• Percentage of backlog items addressed per quarter.
• Content review coverage for key pages.

Ask vendors how they report on these and how often you’ll review them together.

If you want a deeper governance lens on these elements, the earlier article on governance mistakes in redesigns expands why these decisions usually get skipped and then reappear later as chronic support pain.

---

5. Defining Maintenance Maturity for the new site (so you don’t slide back to reactive fixes)

Think of Maintenance Maturity as a ladder from “we fix things when they break” to “we run the website like an operating asset.”

You don’t need the top rung on day one, but you do need to choose which rung you’re targeting with this redesign.

Here’s a simple four-level model:

1. Reactive – Tickets are raised only when something is visibly broken.

   • No planned reviews.
   • Releases are ad hoc and rushed.
   • Metrics are anecdotal (“sales says the form has been flaky”).

2. Scheduled – There’s at least a basic rhythm.

   • Regular release windows.
   • Monthly review of open tickets.
   • Some testing before deploys.

3. Managed – Website is treated as a managed product.

   • Quarterly roadmap and prioritization.
   • Performance, accessibility, and SEO checks on a schedule.
   • Defined error budgets and risk thresholds.

4. Optimized – Continuous improvement mindset.

   • A/B testing and experimentation.
   • Proactive technical debt reduction.
   • Tight integration with campaign planning and product changes.

Where are you today? Where does the new site actually need you to be?

If your redesign adds complexity (more integrations, more flexible content, more traffic), but your support model stays stuck at Reactive, you’re effectively increasing risk.

In our ongoing-website-support work, we use this maturity lens to design support plans that match the site’s ambition. A basic marketing site may live comfortably at Scheduled; a revenue-critical platform often needs at least Managed.

A partner focused on ongoing website support should be able to describe how they’ll move you from your current level to your target, not just how they’ll “keep the lights on.” If you don’t have that, this is the moment to look at an operating model like Ongoing Website Support that is built around Maintenance Maturity instead of isolated fixes.

---

6. Ownership map: who decides what after launch?

Most post-launch friction isn’t about technology; it’s about unclear decision rights.

A simple ownership map can prevent months of confusion.

Map decisions, not just roles

Start by listing the types of decisions your new site will require:

• Content changes to existing pages.
• New pages or campaigns.
• Changes to templates or components.
• Navigation and IA changes.
• Integrations and tracking changes.
• Emergency fixes and rollbacks.

For each, define:

• Accountable – who is on the hook for the outcome.
• Responsible – who actually does the work.
• Consulted – who must be involved.
• Informed – who needs to know after the fact.

You don’t need to publish a full RACI chart in your RFP, but you do need to show vendors the rough map so they can design their support model around it.

A realistic scenario

In many redesigns, there’s a line in the proposal: “includes 60 days of post-launch support.” No detail on what’s covered.

Three months after launch:

• Marketing wants to adjust a high-converting lead form and test a new variant.
• IT assumes the agency will handle it.
• The agency says it’s “out of warranty” and treats it as a small project with a 3–4 week lead time.
• Meanwhile, campaigns are driving traffic to a form that’s underperforming.

Nothing is technically broken—but your operating model is.

A clear ownership map would:

• Specify that marketing owns the form strategy and requests changes.
• Define that the support partner handles component-level updates within an agreed SLA.
• Require that any form impacting revenue gets priority routing and faster turnaround.

Without that, the support queue becomes a negotiation instead of a workflow.

If your main problem today is that your existing vendor is a bottleneck, the piece on support vendors becoming bottlenecks and how to reset the operating model escalates this conversation and can help you decide whether you need a new vendor, a new model, or both.

---

7. Guardrails against Content Drift in your new build

A new site can look pristine at launch and still drift badly within a year.

Content Drift is the gradual loss of accuracy, consistency, search alignment, or conversion usefulness as changes pile up without a clear ownership and review model.

You don’t stop drift with one-off guidelines; you stop it with guardrails built into the support model.

Key guardrails to bake into your redesign and support plan:

1. Standards that live where work happens

• Component usage rules documented in the CMS itself.
• Content templates with required fields (e.g., target audience, key message, primary CTA).
• Simple do/don’t examples for common layouts, not a 100-page PDF nobody opens.

Support implication: tickets that violate these standards should be pushed back or reworked, not quietly implemented.

2. Content review cadence

Define the review rhythm for critical areas:

• Quarterly review for top-converting pages and key funnels.
• Semi-annual review for product or service descriptions.
• Annual review for general evergreen content.

Decide who leads each review and how changes feed into the support backlog.

3. Exception rules

Sometimes you’ll need to move fast (regulatory change, market event, urgent campaign).

Your model should spell out:

• When it’s acceptable to skip parts of the standard.
• Who can approve an exception.
• How and when those pages are brought back into alignment later.

4. Drift monitoring

Someone has to own the question: “Is the site still accurate and on-message?”

That can include:

• Simple quarterly audits of key sections.
• Spot checks of recent changes for consistency.
• Review of support tickets for patterns (“lots of last-minute content changes from sales suggests upstream process gaps”).

A good ongoing support model doesn’t just close tickets; it monitors for drift and raises flags when patterns appear.

If you’re not sure how bad things are today, the earlier article on how to know if your website needs help offers a useful contrast: it helps diagnose whether you’re dealing with localized pain or a systemic ownership problem.

---

8. Support model options to compare alongside your redesign proposals

When you review redesign proposals, compare support models, not just build cost.

Here are four common patterns and their tradeoffs.

1. Ad-hoc hours with no cadence

What it is: A bucket of hours, used on request, no formal SLAs or planning.

Pros:

• Flexible and simple to buy.
• Fine for low-stakes, low-change sites.

Cons:

• No guaranteed responsiveness when you need it most.
• Easy for “small requests” to clog the queue.
• No built-in rhythm for improvements or reviews.

Best fit: Small, low-criticality sites where delays don’t impact revenue or risk.

2. Project-only, with separate support

What it is: One vendor handles the redesign as a project; another group (internal or external) handles post-launch support.

Pros:

• Specialized build team for complex redesigns.
• Flexibility to negotiate support separately.

Cons:

• Knowledge transfer risk between build and support teams.
• Easy to lose strategic context for later changes.
• Support may treat the site as a black box.

Best fit: Organizations with strong internal product ownership and technical depth who can manage the handoff and keep context alive.

3. Integrated redesign + support team

What it is: The same partner designs, builds, and then runs the site on an ongoing basis.

Pros:

• Continuity of knowledge and intent.
• Easier to evolve the site based on real-world results.
• Clear single throat to choke when issues arise.

Cons:

• Risk of over-dependence on one vendor if governance is weak.
• Requires good contracting and exit planning.

Best fit: Teams that want a long-term partner and are comfortable investing in a shared operating model.

4. Internal owner + external ongoing-website-support

What it is: Clear internal website owner (marketing/operations) plus an external partner whose core service is structured ongoing support, not just projects.

Pros:

• Internal control over priorities and roadmap.
• External capacity and expertise for execution and risk management.
• Easier to align with Maintenance Maturity goals.

Cons:

• Requires your internal owner to have time and authority.
• Needs disciplined communication to stay aligned.

Best fit: Serious business websites where the site is revenue-supporting and leadership wants durable ownership without building a large in-house team.

If you want to see what a structured version of option 4 looks like, review how a service built specifically for ongoing website support Ongoing Website Support describes SLAs, cadences, and ownership. That kind of model is designed to run what you just redesigned, not just fix bugs.

For teams already working from a technical or content audit, the article on turning audit findings into a support retainer or project expands how to decide which of these models fits your backlog and risk profile.

---

9. Turning your decision into a concrete next step

You don’t have to solve every governance question this week. But you do need to prevent your redesign from hardening today’s support problems into your new site.

Here’s a short checklist you can act on now:

1. Write down your current support model.
   One page, max: who does what, how tickets flow, SLAs (formal or informal), release cadence.

2. Run the Fit-for-Future Test.
   Compare that model against your redesigned site’s ambition: change volume, revenue dependency, compliance, internal skills, backlog reality.

3. Pick a Maintenance Maturity target.
   Decide which rung of the ladder your new site requires and sanity-check whether your current model can get you there.

4. Update your RFP.
   Add clear expectations for post-launch ownership: roles, scope, SLAs, cadence, escalation, success measures. Remove or rewrite any vague “maintenance included” lines.

5. Choose a support model, not just a vendor.
   When you evaluate proposals, compare the operating models behind them. Ask how they handle ownership, drift, and maturity over time.

6. Name an internal website owner.
   Give someone the mandate to own the site as a product, not a project artifact.

If you want outside eyes on your plan, you can talk through the tradeoffs with a team that specializes in ongoing website support Ongoing Website Support and is used to pairing redesigns with durable operating models.

To explore more angles on redesign decisions, the website redesign topic hub website redesign articles pulls together related pieces—from governance pitfalls to support vendor bottlenecks—so you can move from “we need a new site” to “we know how this site will be owned.”

And if you want help pressure-testing your support model or RFP before you send it out, you can always get in touch to walk through the details and see where the gaps are. contact page