Build vs buy, and how to replace a WordPress plugin without downtime

On most service sites, the contact form is the cash register. A visitor reads the page, decides to trust you, types in their details, and hits send. When that message silently fails to arrive, you lose far more than a form entry. You lose someone who believes they reached you and is sitting by the phone for a call that will never come, while a competitor picks up the job instead. The cruel part is that nobody sees it happen: no error, no bounce, no angry email, just revenue leaking out of the very last step.

That is exactly what nearly happened to me on a real site I run, ampy.se. A bug in the third party forms plugin started silently dropping submissions in production. No error on screen. The visitor saw a friendly thank-you message. The lead never landed in the inbox or the systems behind it. I patched it the same day it broke, then made a bigger decision: I replaced the plugin with a custom system that owns every path a lead travels. I did the whole migration with zero lost leads and no downtime. This is how, step by step, in a way you can copy.

Build or buy: the decision most people get wrong

Plugins are a gift. They save you weeks. For most things on a site, you should absolutely buy, not build. A gallery, a cookie banner, a sitemap: install it and move on. Writing your own version of those is vanity, not value.

So the question is not “can I build this myself”. Of course you can. The question is “is this specific piece worth owning”. I use three tests. If a plugin fails all three, keep it. If it passes all three, it is a strong candidate to replace.

“

The question is never whether I can build it. The question is whether this specific piece is worth owning.

Test one: does it touch money or leads directly?

Some plugins are decorative. If they break, the site looks a bit worse for an hour and nobody loses anything. Other plugins sit on the exact path between a customer and your bank account: forms, checkout, booking, payment. When those fail, the failure is invisible and expensive at the same time. A broken gallery is obvious and cheap. A broken lead pipeline is silent and costly. The closer a plugin sits to revenue, the more owning it is worth.

Test two: how fast does the vendor move when it matters?

When my forms plugin broke, the clock was running against real money. I could not afford to file a support ticket and wait a week for a maintenance release. Ask yourself honestly: if this broke at 9am on a Monday, would the vendor have a fix by lunch? For most plugins the answer is no, and that is fine, because most plugins are not on the revenue path. For the ones that are, a slow vendor is a real business risk you are carrying without pricing it in.

Test three: do you need control the plugin will not give you?

The forms plugin sent an email and stopped there. What I actually needed was a lead that fans out to several places at once: a notification to me, a record in a CRM, a tag for follow-up, and room to add more later without begging a vendor for a hook. When you need that kind of control, a generic plugin becomes a cage. Owning the code turns every future integration into an afternoon instead of a feature request.

The honest cost of building

Building is not free. You now own the bugs, the security, and the maintenance forever. That is the real price, and you should say it out loud before you commit. I only build when a thing is close to revenue, the vendor is too slow to trust with it, and I need control I cannot buy. Forms on a lead-driven site hit all three. That is why this one was worth it.

The part nobody warns you about

Here is the trap. Once you decide to replace a plugin, the tempting move is to deactivate the old one, activate the new one, and hope. On a live site that touches leads, hope is not a plan. If your replacement has one wrong field name or one missed notification, you go straight from “occasionally dropping leads” to “dropping every lead”, and you will not find out until an angry customer calls.

The safe way is boring on purpose. You never flip a switch. You run the old system and the new system side by side, feeding both from the same submission, until you have watched the new one handle real traffic correctly with your own eyes. Only then do you cut over. And you keep the old one one line of code away, so a rollback takes seconds. Let me walk through it.

Building it step by step

Step one: inventory exactly what the plugin does

You cannot replace what you have not written down. Before touching any code, I map every single thing the current plugin does when a form is submitted. Not what I think it does. What it actually does. Open the settings, read the notification templates, check the integrations, and list all of it:

• Every field on the form, with its exact name and whether it is required.
• Every notification: who gets emailed, the subject line, the body, the reply-to address.
• Every integration: CRM, spreadsheet, webhook, tag, anything downstream.
• The validation rules and the spam protection.
• The success message and any redirect after submit.

This list is your contract. The new system must do all of it, or you have quietly dropped a feature a customer relied on.

Step two: build the replacement behind the scenes

I build the new handler as a small custom plugin, completely inert at first. It registers a REST route to receive submissions, but nothing on the live site points at it yet. That means I can build and test it in production without touching a single real visitor.

The core is one honest function that validates input, then does the work. Notice how secrets are read from wp-config constants, never hardcoded. This is the pattern, not a copy of any proprietary source.

<?php
// Register a private endpoint the new form will post to.
add_action( 'rest_api_init', function () {
    register_rest_route( 'bespoke/v1', '/lead', array(
        'methods'             => 'POST',
        'callback'            => 'bespoke_handle_lead',
        'permission_callback' => '__return_true', // public form, we verify a nonce inside
    ) );
} );

function bespoke_handle_lead( WP_REST_Request $request ) {
    // 1. Verify this came from our own form, not a bot hitting the URL.
    $nonce = $request->get_header( 'X-WP-Nonce' );
    if ( ! wp_verify_nonce( $nonce, 'wp_rest' ) ) {
        return new WP_Error( 'bad_nonce', 'Invalid request', array( 'status' => 403 ) );
    }

    // 2. Pull and clean every field from the inventory in step one.
    $lead = array(
        'name'    => sanitize_text_field( $request->get_param( 'name' ) ),
        'email'   => sanitize_email( $request->get_param( 'email' ) ),
        'phone'   => sanitize_text_field( $request->get_param( 'phone' ) ),
        'message' => sanitize_textarea_field( $request->get_param( 'message' ) ),
    );

    // 3. Validate the way the old plugin did. Required means required.
    if ( empty( $lead['name'] ) || ! is_email( $lead['email'] ) ) {
        return new WP_Error( 'invalid', 'Please check your details', array( 'status' => 422 ) );
    }

    // 4. Do the real work, wrapped so one failure never loses the lead.
    bespoke_store_lead( $lead );
    bespoke_notify_team( $lead );
    bespoke_send_to_crm( $lead );

    return new WP_REST_Response( array( 'ok' => true ), 200 );
}

Step three: never lose a lead, even when something downstream fails

The original sin of the old plugin was this: it did one thing, and if that one thing failed, the lead was gone. My rule is the opposite. Store the lead first, locally, before any email or API call. If the CRM is down or the mail server hiccups, the lead is already saved and I can replay it later. A failed integration should degrade the experience, never destroy the data.

<?php
// Save first, always. This must succeed before anything else runs.
function bespoke_store_lead( array $lead ) {
    $post_id = wp_insert_post( array(
        'post_type'   => 'bespoke_lead',
        'post_status' => 'private',
        'post_title'  => $lead['name'] . ' - ' . current_time( 'mysql' ),
    ), true );

    if ( is_wp_error( $post_id ) ) {
        // Even the DB write failed. Log it loudly so a human notices.
        error_log( 'LEAD SAVE FAILED: ' . wp_json_encode( $lead ) );
        return;
    }

    foreach ( $lead as $key => $value ) {
        update_post_meta( $post_id, 'lead_' . $key, $value );
    }
}

// Notifications and API calls are wrapped so a failure is logged, not fatal.
function bespoke_send_to_crm( array $lead ) {
    $api_key = defined( 'BESPOKE_CRM_KEY' ) ? BESPOKE_CRM_KEY : '';
    if ( empty( $api_key ) ) {
        return; // No key set, skip cleanly instead of crashing.
    }

    $response = wp_remote_post( 'https://api.your-crm.example/v1/contacts', array(
        'timeout' => 8,
        'headers' => array(
            'Authorization' => 'Bearer ' . $api_key,
            'Content-Type'  => 'application/json',
        ),
        'body'    => wp_json_encode( $lead ),
    ) );

    if ( is_wp_error( $response ) || wp_remote_retrieve_response_code( $response ) >= 300 ) {
        // The lead is already saved locally, so this is recoverable, not lost.
        error_log( 'CRM push failed for ' . $lead['email'] );
    }
}

That one design choice, save before you send, is the difference between “we had a rough hour” and “we lost a week of leads and nobody knew”.

Step four: run old and new in parallel

Now the careful part. I do not switch anything off. Instead, I make the existing form fire the new endpoint alongside its normal behaviour. The old plugin keeps sending its emails exactly as before. The new system also receives every submission and stores it. Both run on the same real traffic at the same time.

On a real site I do this by hooking the plugin’s own submit event in the browser and mirroring the data to the new REST route. The old path is untouched, so if my new code is wrong, nothing breaks for the customer.

<?php
// Expose the REST URL and nonce to the front end so the mirror can post safely.
add_action( 'wp_enqueue_scripts', function () {
    wp_localize_script( 'bespoke-forms', 'BespokeForms', array(
        'endpoint' => esc_url_raw( rest_url( 'bespoke/v1/lead' ) ),
        'nonce'    => wp_create_nonce( 'wp_rest' ),
    ) );
} );

// In bespoke-forms.js: mirror every real submission to the new system,
// while the old plugin keeps doing its normal job untouched.
document.addEventListener( 'submit', function ( event ) {
    var form = event.target;
    if ( ! form.matches( '.contact-form' ) ) {
        return;
    }

    var payload = {
        name:    form.querySelector( '[name="name"]' ).value,
        email:   form.querySelector( '[name="email"]' ).value,
        phone:   form.querySelector( '[name="phone"]' ).value,
        message: form.querySelector( '[name="message"]' ).value
    };

    // Fire and forget. If this fails, the old plugin still handled the lead.
    fetch( BespokeForms.endpoint, {
        method:  'POST',
        headers: {
            'Content-Type': 'application/json',
            'X-WP-Nonce':   BespokeForms.nonce
        },
        body: JSON.stringify( payload )
    } ).catch( function () { /* old path is the safety net */ } );
}, true );

Step five: verify with real submissions

This is the step people skip, and it is the whole point. I let the parallel run collect real submissions for a few days. Then I compare, one by one, what the old plugin delivered against what the new system stored. Every email the old one sent should have a matching lead in the new store, with every field intact.

I check the boring things that quietly break migrations:

• Do all the fields carry over, including the ones with odd characters, long messages, and non-Latin names?
• Do the notifications land in the inbox, not the spam folder, with the right reply-to?
• Does the CRM record look identical to what the old integration created?
• Do the counts match exactly over the test window? One missing lead means the new path has a hole.

I do not cut over until the two systems agree on real traffic for long enough that I trust it. Trust here means evidence, not optimism.

Step six: cut over, and keep a rollback

Only after the new system has proven itself do I flip the primary path. Now the new endpoint owns the lead, and the old plugin is switched to silent or removed. Crucially, the cutover is a single flag, so undoing it is instant. If anything looks wrong in the first hour, I flip it back and I am exactly where I started, with no data lost either way.

<?php
// One switch controls which system is authoritative.
// Set in wp-config: define( 'BESPOKE_LEADS_LIVE', true );
function bespoke_leads_are_live() {
    return defined( 'BESPOKE_LEADS_LIVE' ) && BESPOKE_LEADS_LIVE;
}

// While false: new system stores in parallel, old plugin still notifies.
// While true: new system owns notifications, old plugin can be retired.
function bespoke_notify_team( array $lead ) {
    if ( ! bespoke_leads_are_live() ) {
        return; // Parallel phase: let the old plugin send the emails.
    }

    $to      = defined( 'BESPOKE_LEAD_INBOX' ) ? BESPOKE_LEAD_INBOX : get_option( 'admin_email' );
    $subject = 'New lead: ' . $lead['name'];
    $body    = "Name: {$lead['name']}nEmail: {$lead['email']}nPhone: {$lead['phone']}nn{$lead['message']}";
    $headers = array( 'Reply-To: ' . $lead['name'] . ' <' . $lead['email'] . '>' );

    wp_mail( $to, $subject, $body, $headers );
}

Keep the old plugin installed but dormant for a couple of weeks after cutover. It costs nothing and it is your seatbelt. Once you have watched the new system carry all the traffic on its own, you remove the old one and the migration is truly done.

Prove it works

A migration you cannot verify is a migration you cannot trust. So I make the new system easy to check at a glance. Every lead is a record in the database, listed in the admin, with a timestamp and every field. If a customer ever says “I sent a message and heard nothing”, I can look. Before, with the plugin, there was nothing to look at, which is precisely how leads vanished without a trace.

I also keep the error log honest. Every failed notification or CRM push writes a line, so a partial failure is something I discover from a log, not from a lost customer. The test is simple: submit a real lead, watch it appear in the store, watch the email arrive, watch the CRM record get created. If all three happen, the pipeline is whole.

The payoff, in business terms

Here is what this actually buys you, past the jargon.

• You stop losing leads and money to someone else’s code. When the thing that catches customers is yours, a vendor’s bad week is no longer your lost revenue.
• Every lead is saved the instant it arrives, before any email or integration runs, so a downstream hiccup can no longer make a customer disappear.
• You control your own pipeline. New integration, new notification, new tag: that is now an afternoon of your own work, not a support ticket and a wait.
• You migrated without a single customer noticing. No downtime, no dropped leads, no risky big-bang switch. Just old and new running together until the new one earned the job.

You do not need to rebuild your whole site or distrust every plugin. Most plugins are fine, and you should keep them. You need to spot the few pieces that sit on the money path, and when one of those lets you down, replace it the careful way: inventory it, build the replacement quietly, run both in parallel, verify with real traffic, then cut over with a rollback one flag away. Do that, and the moment a customer decides to trust you, their message always arrives. That is the whole business right there.