StackEvidence Compare Software
Migration Guide

Migrate to GetResponse without turning the move into a blind cutover.

The safest ESP migration is not “export everything, import everything, and hope.” Preserve the source account, map the data model, import a controlled sample, rebuild the workflows that cannot transfer cleanly, test the complete path, and only then move production traffic.

Follow the migration plan Review GetResponse limitations
Migration model Staged cutover
Strongest portability area Contact data
Highest rebuild risk Automations · pages · integrations
Documentation review October 2026
Before the migration

Protect the business before touching the destination account.

A successful migration preserves more than email addresses. It preserves permission, segmentation logic, business rules, sending reputation, working links, and the ability to roll back if something fails.

Keep the source ESP active Maintain access until the new account has passed the production checklist. Avoid creating a deadline that forces a bad cutover.
Export before cleaning Create an untouched backup before deleting duplicates, suppressions, inactive records, or fields you think you no longer need.
Preserve permission records Keep the best available record of when, where, and how subscribers opted in, including source-system evidence that may not map cleanly.
Inventory every live dependency Forms, automations, lead magnets, domains, integrations, webhooks, ecommerce systems, and tracking links can all depend on the old ESP.
Know the required GetResponse plan Do not discover after migration that the workflow you rebuilt requires a higher plan than the one you purchased.
Verify policy fit first A technically successful migration is still a failure if the destination provider does not permit your actual content model.
Important for affiliate-supported publishers: StackEvidence would not migrate its own production newsletter to GetResponse under the current Compliance guidance on multi-vendor comparison emails. This guide is for businesses whose content model fits GetResponse's current rules.
Staged migration plan

Move one layer at a time.

This sequence reduces the chance that a problem with one layer — contact data, automation, sending, or lead capture — becomes a full business outage.

1

Audit the source account.

Build a migration inventory before creating the new structure. The goal is to identify what must move, what can be retired, and what will need to be rebuilt manually.

Export a raw contact backup
List tags, fields and segments
Inventory broadcasts and templates
Document live automations
List forms and landing pages
Record integrations and webhooks
Preserve suppression / unsubscribe data
Preserve consent evidence separately
2

Clean the migration copy — not the original backup.

Work from a copy of the source export. Remove records you have no permission or business reason to email, resolve obvious duplicates, and standardize the fields before import.

Keep the untouched backup unchanged
Remove known invalid records
Preserve unsubscribes and suppressions
Standardize field names
Normalize dates and categories
Decide what becomes a tag vs custom field
3

Design the GetResponse contact model first.

Do not automatically recreate every list from the old ESP. GetResponse can count one email address multiple times when it exists on multiple lists, so unnecessary duplication can affect cost.

Define the minimum list structure
Create required custom fields
Define tag naming conventions
Plan segmentation rules
Map old list membership deliberately
Avoid duplicate-list architecture by default
4

Import a controlled sample before the real audience.

Use a small, representative batch that exercises the important fields and segments. StackEvidence used this approach during hands-on verification rather than putting a real audience at risk.

Include several realistic contact types
Map name and email
Map or create custom fields
Assign required tags
Confirm the target list
Verify imported values after processing
5

Rebuild and verify segmentation.

Segment names are less important than segment logic. Recreate the actual conditions the business needs and confirm expected sample contacts enter and leave each segment correctly.

Rebuild high-value segments first
Test multi-condition rules
Compare expected vs actual membership
Document every production segment
Check exclusions and suppressions
Avoid assuming old ESP logic is identical
6

Rebuild email templates and test real messages.

Recreating the visual design is only part of the job. Verify personalization, links, mobile presentation, sender identity, reply handling, footer requirements, and tracking.

Rebuild the minimum production template
Test personalization
Check every link destination
Review desktop and mobile preview
Send controlled test messages
Verify sender / reply-to configuration
7

Rebuild automations from the business logic.

Treat the old automation as a specification, not as something guaranteed to transfer automatically. Recreate the trigger, waits, conditions, branches, actions, tags, and messages inside GetResponse, then test each route.

Document the source workflow first
Rebuild the trigger
Recreate waits and timing
Rebuild branch conditions
Verify tags and field changes
Test YES and NO paths independently
8

Replace lead-capture assets carefully.

Forms and landing pages may be embedded or linked across the website, advertisements, lead magnets, social profiles, QR codes, and partner content. Replacing the page inside GetResponse does not update those outside references automatically.

Rebuild critical forms
Recreate required consent copy
Test success / thank-you behavior
Update embedded form code
Replace old landing-page links
Test every live acquisition path
9

Validate reporting, tracking and integrations.

A message that sends successfully can still be operationally broken if the business loses attribution, CRM updates, conversion tracking, webhook events, or link-management data.

Verify tracked links
Check analytics connections
Validate CRM / ecommerce integrations
Test webhook or API events
Verify conversion destinations
Preserve baseline reporting from old ESP
10

Import the production audience in controlled batches.

Once the structure is proven, move the real audience with enough control to identify errors. Do not mix a large import, a major template change, new automations, and a domain change into one unobservable event if you can avoid it.

Import only permissioned contacts
Watch import results and rejected records
Validate field mapping after each batch
Check segment membership
Confirm suppressions remain respected
Document the migration date and source
11

Run a controlled production period.

Keep the old system available while GetResponse handles a small number of real workflows or messages. Watch for unexpected subscriber behavior, missing fields, automation branches, broken links, or attribution failures.

Send a controlled production broadcast
Observe automation enrollment
Check replies and support routing
Review unsubscribes and suppressions
Verify forms continue adding contacts
Compare expected reporting with actual data
12

Decommission the old ESP only after rollback is unnecessary.

Archive the final exports, reports, screenshots, configuration notes, consent evidence, invoices, and any other records that may be useful after the source account disappears.

Create final source-account exports
Archive key reports
Preserve consent / permission evidence
Confirm no forms still point to old ESP
Confirm no automations remain required
Then follow the source provider's cancellation process
Portability reality

Some things migrate. Some things are better treated as rebuilds.

This distinction prevents a common migration mistake: assuming that because subscriber data can be imported, every part of the previous marketing system is portable in the same way.

Contacts
Good migration candidate Email, name and supported custom field values can be imported through GetResponse's contact-import workflow.
Still verify Permission, suppressed status, unusual source fields, duplicates, formatting, and the final contact count.
Tags
Good migration candidate GetResponse supports tags and allows tag assignment during contact management/import workflows.
Still verify Naming conventions and whether the source ESP's tag logic maps cleanly to GetResponse.
Custom fields
Good migration candidate Fields can be mapped to existing GetResponse fields or new custom fields can be created during import.
Still verify Field type, character limits, date formats, empty values, and normalization.
Consent evidence
Protect separately Preserve the original evidence of opt-in and lawful permission outside the ESP before migration.
Do not assume Do not assume every consent object or historical proof will map one-for-one between platforms.
Segments
Rebuild logic Import the underlying contact attributes, then recreate the segment conditions in GetResponse.
Verify membership Check sample contacts against the expected result before using the segment for production sends.
Automations
Treat as rebuild Document the old workflow and reproduce its business logic using GetResponse automation elements.
Verify every branch Trigger, waits, conditions, actions, tags, messages and exit behavior all need testing.
Forms & pages
Treat as rebuild Recreate the live asset in GetResponse or retain an external form/page.
Verify external references Update embeds, URLs, thank-you flows, analytics and lead-magnet delivery.
Historical reporting
Archive first Save important source-platform reports before closing the old account.
Expect a baseline reset New GetResponse reporting begins from the activity generated inside the new account.
GetResponse import details

Prepare the contact file deliberately.

GetResponse's current import tools are flexible enough for most standard subscriber migrations, but the file still needs to meet the platform's requirements.

Supported file formats Current documentation supports CSV, TXT, VCF, XLSX and ODS, plus legacy XLS with a lower file-size ceiling.
File-size limits CSV, TXT, VCF, XLSX and ODS can currently be up to 50 MB. XLS files can currently be up to 10 MB.
UTF-8 formatting GetResponse recommends preparing import files in UTF-8 encoding and using supported column delimiters.
Email is required Email is the core required contact field. A column named “name” can be recognized automatically for the contact name.
Custom-field mapping Existing fields can be mapped during import, and new custom fields can be created during that mapping step.
Permission requirement GetResponse requires imported contacts to be people you have permission to add and email.
Do not import simply because a record exists in your old ESP. A historical database can contain unsubscribed, suppressed, stale, purchased, role-based, or otherwise inappropriate addresses. Migration is a good time to distinguish records you own from people you are actually permitted to email.
Permission & consent

Treat permission evidence as a business record, not merely an ESP field.

Consent can be more complicated than a single boolean field. Preserve the source evidence even if the destination account has its own consent-field system.

Keep the source export Preserve subscription dates, source, form information and any available permission-related data from the old platform.
Keep external records when available Store relevant signup logs, purchase records, form versions, campaign records, or other proof that does not depend solely on the ESP account remaining open.
Rebuild current consent collection Configure the GetResponse forms and landing pages so new subscribers are asked for the consent required by your actual business and jurisdiction.
Why StackEvidence is conservative here: GetResponse's current documentation exposes useful consent functionality, but the safest migration practice is still to preserve the original permission evidence independently rather than relying on a one-click consent-history transfer.
Final cutover checklist

Do not cancel the old platform until these are true.

Contacts match expectations Production contacts, required fields, tags, exclusions and segments have been checked after import.
Sending identity works Sender address, authentication, reply handling, footer details, tests and production messages function as intended.
Critical automations are proven Realistic test contacts have completed every important automation route without an unexplained failure.
Lead capture reaches GetResponse Every important form, page and signup route has been tested from the public website through the resulting subscriber record.
Tracking still works Links, analytics, conversions, CRM updates and integrations have been verified after migration.
Rollback is no longer needed The new system has operated long enough that shutting down the source account does not remove a critical fallback.
StackEvidence migration rule

Migrate the audience once. Test the system many times.

The expensive part of an ESP migration is not uploading a CSV. It is preserving the business logic around that audience — permission, segmentation, automation, acquisition, tracking, reporting and customer experience.

Contacts Strongest portability area. Export, clean, map, import and verify.
Workflows Treat as business logic that may need reconstruction rather than assuming direct cross-platform portability.
Cutover Keep both systems available until the new environment has survived controlled real-world operation.
Review GetResponse Limitations Read the GetResponse Review
Migration evidence

What supports this migration plan.

The guide combines current GetResponse import/export documentation with StackEvidence's controlled hands-on migration-style testing. Areas that were not directly proven are treated as rebuild or verification tasks rather than assumed portability.

Current contact-import documentation File formats, file-size limits, permission requirements, autoresponder options and the current Add contacts workflow.
Current field-mapping documentation Mapping existing custom fields and creating new fields during import.
Current export and API documentation Contact export plus broader API access to lists, newsletters, workflows, reports and other account objects.
StackEvidence hands-on testing Controlled import, custom fields, tags, segmentation, automation, forms, landing pages, reporting and contact export.
Known evidence boundary StackEvidence did not perform a destructive real-business migration or prove one-click portability of a complete configured ESP account.
Commercial transparency

Migration guidance should reduce switching risk, not force a vendor sale.

This page currently contains no GetResponse affiliate link. A reader who discovers during migration planning that GetResponse is the wrong fit should be able to stop before moving a production audience.

Before migrating: review the current pricing , the documented limitations , and the GetResponse vs ActiveCampaign comparison before committing a production list.
Compare Email Platforms Affiliate Disclosure