Business email compromise during a mail migration: what breaks and what to freeze

A mail move changes what normal looks like. During cutover, unfamiliar messages about accounts, addresses and passwords arrive while staff are occupied, and business email compromise can blend into legitimate change. Evidence is split between old and new systems, one of which may be canceled, so retain useful records and freeze payment changes.

Which payment changes should I stop during cutover?

Block changes to bank details, payee records and payroll deposits from one week before cutover through one week after it. Refuse every request during that period instead of queuing it, including one presented as urgent; requests should not be left waiting for later approval.

Usually, the freeze needs to cover only the period when unusual migration messages are expected, a few days on either side rather than weeks. If you choose the full week-before and week-after schedule, state the end date at the outset so the pause is not quietly broken or left open-ended.

Whenever migration information goes to suppliers, include the freeze and its end date. A legitimate change can wait; if an exception is unavoidable, verify it by voice using a number already held and record who approved it. One exception is manageable, and any accumulated requests should be staggered after the freeze rather than rushed through.

What can fail when mail starts flowing on two platforms?

Check authentication, forgotten senders, mailbox settings, audit history, old-system access, shared addresses and second-factor enrollment both before and after cutover. Failures can interrupt delivery or weaken oversight and payment verification, so check each area on both sides of the move rather than treating migration as one technical switch.

Published email authentication records identify which services may send as your domain. When both platforms send during dual delivery, cover each one without making the records permissive enough to authorize everyone. Adding the second platform can also push records beyond their length and lookup limits, causing failures that seem unrelated to the move.

During the transition, return any stricter policy to monitoring and review reports until every sender is recognized; only then tighten it again. Reversing that sequence can stop your own invoices from arriving. The NCSC explains the records and sequencing in its email security and anti-spoofing guidance.

Invoicing, booking, newsletter and accounting services that send statements may use your domain too. A former employee may have configured one years ago and left no clear record. These forgotten sources often surface after migration when a customer says an invoice never reached them.

Mailbox rules, forwarding and delegates are settings, not messages, and may not transfer. Review them across the business and rebuild deliberately: users may recreate remembered settings without oversight. Alerts for every new rule can then fire so often that the person monitoring them learns to ignore the warnings.

The new tenant starts without the old audit history, while pre-cutover activity stays in the previous system and its retention period keeps running. Export or extend those records before cancellation, and note where the export is stored. Keep records for later review, because questions can arrive after migration work is finished.

Accounts can stay enabled, existing sessions can remain valid, and the former service may accept mail for a time. An abandoned address still receiving messages in an unmonitored place is a genuine exposure, and the new platform will not reveal it. Inspect residual access rather than assuming cutover removed it.

Distribution lists, aliases and shared mailboxes do not always map cleanly. Check the finance address manually: if one member disappears from a shared mailbox, a verification reply may reach nobody. Confirm that the intended people still belong to every relevant group and shared address instead of trusting automatic mapping.

Second-factor registrations do not transfer, so users must enroll again. Expect people to see an unfamiliar prompt and potentially approve it; plan this as a specific risk, not routine administration. Re-enrollment also allows a stronger method at no extra cost; CISA's multi-factor authentication guidance helps with method choice.

What should I keep from the old mail system?

Keep the previous environment and its evidence available until relevant records are exported and the replacement has been tested. An earlier compromise, an old address or a session that remains active may outlast cutover, so do not cancel or close the old service before those checks are complete.

How can I make the cutover less risky?

Pick a date outside month end, your busiest trading period and the fortnight around payroll. Avoid month end, since a finance deadline can make skipped verification more likely when teams must decide what to drop. Leave room for checks before and after the transition.

Publish and verify the new platform's authentication records before any mail flows. Begin with technically comfortable people who do not handle money, resolve what they find, then move the remaining staff by department rather than changing everyone at once. This lets you correct problems before the wider rollout.

Move finance neither at the beginning nor the end: early placement makes staff test an unproven setup while approving payments, while late placement invites a rushed transition. Warn suppliers and customers before the change through a channel other than email, and state plainly that bank details are not changing.

Keep the migration notice brief and clear that payment details are unaffected, and tell suppliers when the freeze ends. For money-related changes, other payment channels offer options beyond email. Keep the notice simple so payment instructions remain unambiguous, without making the message complicated.

Should I move finance systems at the same time?

No. Separate the finance-system cutover from mail by enough time for the first transition to finish before starting the next. Moving both at once leaves no stable reference for ordinary activity, making changes harder to spot and payment checks less reliable.

What should I verify in the first fortnight?

Use the first fortnight to inspect mailbox settings, prove alerts reach a person, check old addresses and reconcile payment details. People still remember what they changed, so verify the new setup promptly instead of assuming it carried over without error during this review period.

Review every rule, forwarding address, delegate and connected application in the new system, and ask each user to confirm their own mailbox settings. Rebuild alerts for rule or forwarding creation, then trigger a test to prove that a person able to act receives it.

Find old-platform addresses that still accept mail and shut them down properly. Compare supplier payment details with your records and each supplier's latest statement. Confirm that authentication records include exactly the senders now in use, with no extra senders, and lift the freeze only after all of these checks are complete.

If anything seems wrong, do not dismiss it as migration noise: that reflex creates risk. The ordinary evidence checks still apply. Stop the migration, not the investigation; a partly moved estate is harder to examine, and schedule pressure can enlarge a small finding. Follow the incident response sequence, then restart after the investigation.

Who should own the migration and payment controls?

Name one person to run the migration and a different person to oversee payment controls. The migration owner will be occupied, so keep the responsibilities separate. This division matters more than a tooling choice and follows the control ownership principles relevant to the task.

What to do first