Move off GovDelivery and take your subscribers with you
We run the migration. Your subscribers, the topics they picked, your bulletin history, and your templates and branding come across into one account. Residents keep getting what they signed up for, from you, at the same addresses.
- Subscribers come with you
- Topic preferences preserved
- Published bulletins stay readable
- No pause in sending
Want the platform it moves onto? See the resident CRM underneath it.
Five steps, and your staff sign off before anything reaches a resident
We go through your current program with you: audiences, topics, sending addresses, templates, and how much you send. You get it in writing, including what we are not sure about, before any work starts.
We set PublicInput up to match how you communicate today. Topics, templates, branding, sending addresses, admin users, and permissions are all in place before anything is loaded.
Subscribers and the topics they are signed up for are loaded into your account, along with your bulletin history. Nothing sends while this is happening.
You check the result against your own records: counts by topic, opt-outs, past bulletins. We run test sends to addresses you pick. Nothing reaches a resident until you say go.
You pick the date. Sending moves to PublicInput and we stay with your team through the first live campaigns.
Almost all of it is carried across by software. Three things need a person at your agency.
The whole program comes with you
Carried across by software and checked item by item.
Three items stay with your team
The DNS change is one record so mail keeps sending from your own domain. The other two are decisions only you can make.
Your PublicInput account
One account holding your subscribers, your topics, your history, and your branding, sending from your own domain on the day you choose.
The record of who you reach moves with you
The record of who you reach, what they asked to hear about, and what you have already sent moves with you.
Subscribers
Your subscriber records, with the contact details you already hold for them.
Topic subscriptions
Which residents signed up for which topics, so people keep getting what they asked for.
Opt-outs and suppressions
Everyone who unsubscribed stays unsubscribed. Opt-out state carries over with the record.
Bulletin history
What you sent, when you sent it, and which audiences it went to.
Engagement records
Delivery, open, and click history, kept with the bulletin it belongs to.
Templates and layouts
Your bulletin and newsletter formats rebuilt in the drag and drop builder.
Branding
Logo, colors, header, and footer, applied across your templates and pages.
Sending addresses
Your from and reply-to addresses, authenticated on your own domain.
Signup pages
A subscriber portal where residents pick topics and manage their own preferences.
Admin users and roles
Your staff, in the departments and permission levels they work in today.
Old links residents saved keep working
If you publish bulletins to a public archive, residents have those links. They are in press releases, on your website, in search results, and saved by people who wanted to read them again later.
Every published bulletin gets its own page
Those bulletins come across. Each one gets its own page in your PublicInput account, showing the bulletin the way residents saw it, at a permanent link you can share.
Two additions on every published page. One is a language menu, so a resident can read a bulletin from two years ago in their own language. The other is a signup form, so someone who lands on an old bulletin from a search result can subscribe right there.
Plan for the old links
Your existing archive links point at your current vendor's servers, so we cannot redirect them. They keep working while that account is open and stop when it closes.
During the migration you get the list of old links matched to their new ones, so your web team can update your own site before the old account goes away. Links on somebody else's site, like an old joint press release, will need the new address from you.
The cutover is not an event for the public
| For a resident on your list | Before cutover | After cutover |
|---|---|---|
| The topics they signed up for | The topics they picked | The same topics, still theirs to change |
| Who the email is from | Your agency, your domain | Your agency, your domain |
| If they unsubscribed | Off your list | Still off your list |
| A bulletin link they saved | Opens the published bulletin | Opens the same bulletin at your new link |
| Signing up for updates | Your signup page | Your signup page, with the same topics |
| Reading it in another language | Depends on the bulletin | A language menu on every published page |
Nobody has to re-subscribe or confirm anything.
The record of who you have communicated with is your record
When an agency sends a notice to a resident, that is the agency communicating with its own community. The record of who you have communicated with, and what you communicated about, is your record. It documents a relationship your agency built and maintains.
So bringing your subscribers across is part of the job we take on. Topic subscriptions come with them, and residents keep receiving the notices they signed up for.
We look at your program before the migration starts, tell you what we expect to recover, and put the scope in writing so you know what you are getting before you commit.
We need three things from your team: access, review time, and a cutover date
Five things from your side
- Access to your current communications account
- A DNS change so mail sends from your own domain
- Your admin users and what each one should be able to do
- A look at the migrated topics, counts, and test sends
- A cutover date that works for your calendar
The rest of it
- Scope the migration and write down what will move
- Build your account, topics, templates, and branding
- Bring subscribers and their topic preferences across
- Move your bulletin history and give published bulletins new pages
- Authenticate your sending domain and run test sends
- Train your staff and stay with them through the first live campaigns
The sequence is the same for every agency
How long it takes depends on the size of your program and how quickly your team can review, so we put real dates against these phases during scoping.
Scoping
A working session with your team, then a written scope. You decide whether to go ahead once the scope is in writing.
Build and load
Account setup, templates, branding, and bringing your audience and history across. Your team is not blocked and keeps sending from your current system.
Your review
Usually the longest phase, because it depends on staff having time to check counts, topics, and test sends. The phase ends when your review does.
Cutover
Sending switches to PublicInput. We stay with your team through the first live campaigns.
We schedule cutover around your quiet periods. Agencies with a heavy notice calendar, like a construction season or a hearing schedule, usually cut over between cycles so no notice is caught in the middle.
What you get on the other side of the migration
AI assisted campaign building
Draft a bulletin from a starting point instead of a blank page. Staff edit and approve every send.
Language access in the builder
Translate a campaign into the languages your community speaks from inside the builder. Published pages carry a language menu for residents too.
Accessibility checking before send
An accessibility check runs against your campaign before you send it and tells you what to fix. You fix it in the draft before it sends.
Email and text from one place
Run email and text campaigns from the same account, against the same audience and the same topics, instead of keeping two systems in step by hand.
Built on a resident database
Every subscriber is a resident record. Someone who gets your notices, answers a survey, and speaks at a meeting shows up as one person with all of it attached.
A portal residents manage themselves
Residents choose their own topics and update their own preferences, which keeps your lists accurate without staff handling each request.
Bring us your current setup
We will walk through what a migration would cover for your program, what we would need from your team, and the timeline.