May 5, 2026

If your nonprofit (or membership organization) runs a platform that serves a lot of existing clients, modernization can feel risky for one simple reason: trust.

In this particular case, we support 2,500+ websites. The “edge” of the platform (domains, redirects, SSL certificates) is not just infrastructure. It is part of the user experience. If it breaks, staff lose time, donors lose confidence, users flood the front desk with calls, and small issues turn into big support spikes.

We are in the middle of modernizing the edge layer of this legacy platform. We are not done yet, but we do have a clear approach that keeps the work safe, measurable, and reversible.

This is not a “what tool did you pick?” post. It is a scoping and risk-management playbook. If you are staring down a legacy project and you want a plan that includes rollback, clear communication, and work broken into sane sub-projects, here is the checklist we use.

1) Define success in plain English

Before we choose tools or even start with a technical plan, define your outcomes. For our project:

  • No widespread “certificate” errors in browsers
  • No broken redirects or login loops
  • No surprise downtime during business hours
  • A rollback plan that is tested and re-tested (not just imagined)
  • A support plan for client-controlled domains

If we cannot measure these, you cannot manage the migration.

2) Scope by risk

Not all parts of the edge are equally risky. Scoping by risk keeps the project from becoming one giant, fragile cutover. We started by splitting the work into “risk zones”:

  • Highest risk: SSL certificates and custom domains
  • High risk: redirects and rewrite rules (these can break user journeys)
  • Medium risk: host-based routing (where requests should go)
  • Lower risk: internal services behind the edge

This matters because it lets you split the project into sub-projects based on risk. Lower or medium-risk elements can be configured, tested, and released before addressing the high-risk areas. Or you can create a sub-project that fetches the majority of certificates before any redirects are altered.

3) Inventory what is real

At scale, the biggest hidden risk is stale data. Inventory what is truly real, not what you think is real, not what the client tells you is real, not what you hope is real.

You might need an initial “data analysis” sub-project to create, and then validate, a single source-of-truth set of lists. In our case, those lists include:

  • Which domains are active today?
  • Which domains are controlled by our organization vs controlled by clients?
  • Which domains are “special cases” (wildcards, portal domains, legacy redirect-only domains)?

This inventory is the foundation for everything else.

4) Decide what counts as a first-class deliverable

One of the easiest ways to derail a legacy modernization is to treat critical behavior as “just configuration.”

Name the sub-projects that deserve their own scope, test plan, and definition of done. For edge modernization, that typically includes:

  • Certificates: issuance, storage, renewal, and failure handling
  • Redirects: canonical host decisions, one-hop redirects, and redirect mapping
  • Routing: host rules, service mapping, and safe defaults
  • Rollback: documented steps, tested procedure, and target rollback time
  • Client communication: templates, timelines, and “what we need from you” checklists

This is how we keep “small” items from becoming surprise outages.

5) Separate configuration problems from operational systems

This is the move that prevents outages.

  • Routing is mostly a configuration problem. It can change quickly.
  • Certificates are an operational system. They take time, they can fail, and they are constrained by external rate limits.

Treat them as separate workflows. If you tie them together, a certificate delay becomes a platform outage.

6) Avoid big-bang cutovers

If you have thousands of items that require change, thousands of domains that each require complex certificates, do not plan to “flip the switch” and hope for the best.

Instead:

  • Start with the domains you control (the fast path)
  • Issue certificates in small batches (per hour or per day)
  • Track outcomes: issued, failed, retry later
  • Increase batch size only when failure rates are low
  • Schedule the actual delivery cutover only for after reaching a “percentage complete” point

This turns a risky migration into a predictable timeline.

7) Handle special cases explicitly

Don’t let the special cases hide in the long tail. Sometimes the last 5% takes 25% of your time. Account for it.

Most platforms have a small subset of items that don’t behave like the rest. For us:

  • A portal domain that must always be HTTPS
  • A wildcard domain that serves many sub-sites and must always be HTTPS
  • Legacy domains that exist only to redirect to the canonical site
  • A small percentage of CNAME domains that require a different challenge type

Put these on a short list with:

  • Named Owner
  • Certificate source
  • Redirect rules
  • Test plan

8) Call out the things that will make your support desk ring endlessly

This is item eight, but it deserves to be woven through every other item on this list.

Thinking about actual people and their needs pulls you out of a myopic focus on technical details. It makes you consider the bigger picture, including the lives of the support staff who will be flooded with questions (and sometimes mistreated) when a disruption affects their users.

In our case, redirect chains are a common source of “everything is broken” tickets.

We create a redirect map that answers:

  • What is the canonical hostname (for example, www vs non-www)?
  • Which legacy domains should redirect, and where?
  • Can we reduce multi-step redirect chains to a single canonical redirect?

This protects user journeys, preserves SEO value, and helps stop people from noticing that a big change happened under the covers.

9) Build rollback into the plan (and practice it)

A rollback plan is only real if it has been practiced, multiple times, in a staging environment that’s as close to production as possible. In our case:

  • Keep the old edge available until the new edge is proven
  • Document the exact steps to revert
  • Define a rollback target time (for example, 15 minutes)

This is what lets you move fast without being reckless.

10) Communicate clearly

There have been many times in my career that I have communicated a scheduled change to a client and wasn’t sure it was truly necessary. Every time I was glad I did.

Invariably there is a question asked that we hadn’t considered, or a timing issue (someone is out of the office, a campaign is launching, a board meeting is coming up) or any other perspective that changes our approach.

In our case, some end users control DNS settings. Our client needs time to communicate the change to them, ask them to comply with a few quick steps, and support them through the change. Many won’t respond until it breaks for them.

  • Set expectations early
  • Provide a simple client checklist
  • Maintain a “known issues” page for the internal team
  • Decide what “signoff” means (what we test, who approves, and when you call it done)
  • Prepare a script for the end users who ignored your outreach but will call in for help

This prevents the migration from becoming a customer support crisis full of surprises.

The takeaway

Modernizing a legacy platform is not just a technical project. It requires scoping discipline, risk-management, and clear communication.

If you are planning a similar legacy modernization and want a second set of eyes on your risk plan, we are happy to help. We can help you turn a daunting migration into a set of contained projects with clear definitions of done, tested rollback plans, and communication that keeps your team (and your users) calm.