Documentation

Migration and rollback

Move your email to SendHog in small steps, with a way to switch back if needed.

Start by moving one kind of email, such as a sign-in message or a receipt. Keep your current provider running until you have checked that the new setup works. Rollback means switching that email back to your previous provider if something goes wrong.

Choose your provider for specific steps. We remember this choice across the guides and code examples. If there is no matching SDK style, the examples use SendHog’s own library.

Migrate from your current provider

Keep your current provider available during migration. Before switching, verify your SendHog domain for automatic sending approval. Confirm your limits cover your needs and blocked recipients will stay blocked.

Starting a new application?

Use SendHog’s own code library and follow Getting started. You do not need to choose another provider’s SDK style.

Already using another email service? Select it above for the steps to move and switch back safely. Keep that service active until SendHog is ready for live email.

Code example: SendHog. If your provider does not have a matching SDK style, this shows SendHog’s own library; the provider’s migration steps above still apply.

Send email
Provider
import { SendHog } from '@sendhog/sdk';

const client = new SendHog(process.env.SENDHOG_API_KEY ?? '');

const { id } = await client.send({
  "from": "sender@example.com",
  "to": "recipient@example.net",
  "subject": "Hello from SendHog",
  "text": "Hello from your application."
});
console.log(id);
From the SendHog repository · not yet publishednpm install @sendhog/sdk

Write down your current setup

Note what causes the email to be sent, who receives it, the sending domain, daily and monthly volume, and the provider you use. Include templates, repeat attempts and any automatic delivery notifications your application depends on.

Save the current code and settings so you can restore them. Keep existing domain records and provider access. Record your actual costs so you can compare them later.

Start with one kind of email

  • Choose a small, low-risk use case and someone responsible for checking it.
  • Keep unsubscribe and blocked-address lists. These are sometimes called suppression lists.
  • Confirm you are allowed to contact the recipients and that your sending domain is verified.
  • Check which sending features SendHog supports and how your application handles errors.
  • Confirm sending is enabled and account limits cover the emails you plan to send.

Your developer will replace the provider package, client setup and credentials with the SendHog SDK. Supported sending calls can stay familiar, but changing only the server address will not work. Receiving is not yet available. Keep your current provider active until you have verified the migrated workflow and its rollback.

Test before moving more email

Once sending is activated, send a test to someone who has agreed to receive it. Check that the request succeeds, the email arrives and the saved message status is correct. Test how your application handles failures and avoids duplicate emails. Confirm blocked recipients remain blocked.

Monitor costs, usage and support needs over time. One successful test does not prove every kind of email is ready to move.

Keep a way to switch back

Keep your old provider active until the new setup has passed your checks. Write down the settings to restore, who can approve the switch and what to do with emails already being processed.

  • Check whether a message was already accepted before sending it again through either provider.
  • Keep unsubscribes and blocked addresses honored in both systems.
  • Keep API keys private; do not put them in notes or reports.
  • Test switching back with an agreed test recipient before relying on it.
Before changing live email: agree on the change with the account owner. Check the domain, sending settings, limits and billing rules first.