This migration is not about replacing every Google tool. It is about replacing the parts of Google Workspace you are overpaying for. In most cases, the target setup looks like this: keep your domain, route public-facing aliases through Forward, and continue using a familiar inbox workflow for daily email.
That means you should not start by canceling Google Workspace. Start by inventorying which
addresses really need a full inbox and which ones can become forwarded aliases such as
hello@, support@, sales@, and billing@.
Before you migrate from Google Workspace
Ask one question first: are we replacing seats or replacing public-facing aliases? If the business still needs a separate hosted inbox for each employee, keep Workspace or another mailbox provider. If most addresses are just brand-facing entry points that route into one or two working inboxes, forwarding is usually enough.
Pre-migration checklist
What should move to forwarding?
The best candidates are public-facing addresses that do not need their own mailbox login.
hello@yourdomain.comsupport@yourdomain.comsales@yourdomain.combilling@yourdomain.comfounder@yourdomain.comif one inbox owner handles it anyway
Bad candidates for immediate migration are true employee inboxes, heavy collaboration inboxes, or any address tied to shared-drive permissions, compliance policies, or admin controls inside Google Workspace.
Quick comparison
| Need | Keep Google Workspace | Move to Forward |
|---|---|---|
| Employee mailbox with independent login | Yes | No |
| Public-facing alias routed into an existing inbox | Overkill | Yes |
| Shared drives, admin policies, device management | Yes | No |
| Lean branded email with lower recurring cost | Weak fit | Yes |
Step-by-step: migrate from Google Workspace to email forwarding
1. Audit your current Workspace setup
Export a list of users, aliases, and groups. Decide which addresses stay as full inboxes and which ones become forwarded aliases. This prevents accidental deletion of addresses that still need a mailbox.
2. Back up important mailbox data
If a Workspace mailbox is going away completely, export its contents first. Use Google Takeout or the Workspace data export tools if you need a long-term archive.
3. Create the domain in Forward
Add your domain in Forward and prepare the target aliases you want to recreate. Do this before touching DNS so the receiving side is ready.
4. Recreate aliases as forwarding rules
Map each public-facing address to the inbox that will own it after migration. Example:
hello@yourdomain.com-> founder inboxsupport@yourdomain.com-> ops inboxbilling@yourdomain.com-> finance inbox
5. Prepare send-as or reply workflow
If the destination inbox uses Gmail, configure branded send-as before the cutover. This is the step many teams miss. Receiving mail is easy. Replying as the branded address is what makes the setup feel complete.
6. Change MX records only after testing
Once aliases and reply workflow are ready, update your MX records to route new inbound mail through Forward. Test with internal and external addresses immediately.
7. Keep old Workspace inboxes alive briefly
Do not cancel every Workspace seat on the same minute you change MX. Keep critical inboxes alive during the transition window so you can catch unexpected routing issues or reset emails still going to the old accounts.
8. Decommission only what you no longer need
After tests pass and mail flow is stable, remove the Workspace seats or aliases you no longer want to pay for. Keep any remaining Workspace users that still need full inboxes or Google-native collaboration features.
What not to cancel immediately
- admin access tied to your domain verification and billing
- mailboxes still receiving password resets or vendor notifications
- accounts linked to shared drives or Google-only collaboration permissions
- any inbox that has not been fully audited for dependencies
Common migration mistakes
Cutting over before branded replies work
Teams test inbound mail and assume they are done. Then replies go out from the wrong address. Always test both directions.
Deleting inboxes that still own SaaS logins
A mailbox can look unused until a billing alert or password reset fails. Audit vendor and banking logins before deleting old seats.
Moving true employee inboxes into one shared destination
Forwarding is best for branded routing, not for pretending five employees share one login. If users need independent mailboxes, keep them on Workspace or another mailbox provider.
When not to migrate away from Google Workspace
Do not force this migration if your business depends on:
- shared drives and document permissions tied to Workspace users
- device management and security controls from the admin console
- compliance, retention, legal hold, or audit workflows
- a separate hosted inbox for each employee
In those cases, Workspace is still doing real work for you. The better play may be to keep some seats and only move the alias layer to Forward.
Related guides
Read Best Google Workspace Alternative for Custom Domain Email if you are still evaluating the decision, and How to Set Up Professional Email for Your Domain if you need the general setup path after migration.
Bottom line
Migrating from Google Workspace to email forwarding works best when the business mainly needs branded aliases, not a full mailbox suite for every user. Done carefully, the move cuts cost without making the company look less professional.
The safe path is simple: audit first, recreate aliases, verify branded replies, change MX, then reduce Workspace seats only after the new flow proves stable.