Your merger has two clocks. The one nobody schedules is the member notice.
A credit union merger runs on a calendar set by federal rule. Members of the merging credit union must be notified at least 45 and no more than 90 days before the vote, and that notice has to state in writing which branches close and which stay. That is a technology answer, due months before the technology work finishes. This page is about what has to be decided early, and what has to be true on closing day.
- The statutory windows come straight from 12 CFR Part 708b, quoted on this page
- Microsoft blocks a mailbox move outright when the mailbox is on any kind of hold
- Three prerequisites have long lead times and none of them can be compressed at the end
What does the NCUA merger process actually require, and when?
The merger calendar is not a project plan anyone at either credit union gets to set. Most of it is written into federal rule, in calendar days, and it runs in one direction.
Part 708b of title 12 of the Code of Federal Regulations governs mergers of federally insured credit unions. Read as a schedule rather than as a rulebook, it produces a fixed sequence with four hard numbers in it.
The merger plan comes first, and it is detailed
Once both boards approve the idea, the two credit unions prepare a merger plan. The rule lists eleven things that plan must contain, and several of them reach into operations rather than finance: provisions for notifying and paying creditors, and an explanation of any changes relative to insurance such as life savings and loan protection insurance and insurance of member accounts.
The plan then goes to the NCUA Regional Director with a submission package that includes the proposed merger agreement, the proposed notice of special meeting, a copy of the member ballot, and one item that surprises people the first time they see it: board minutes for both credit unions referencing the merger for the 24 months before the date the boards approved the merger plan.
Source: 12 CFR 708b.103 and 708b.104, via the Legal Information Institute.The member notice is the moment everything locks
This is the hinge of the whole timeline, and it is the reason this page exists.
"Members of the merging credit union must receive written notice at least 45 calendar days, but no more than 90 calendar days, before any member meeting called to vote on the merger proposal."
12 CFR 708b.106(a)A 45 day floor and a 90 day ceiling is a narrow landing zone, and the rule then specifies what has to be inside that notice. Two of the required disclosures are pure operations:
"A statement identifying the physical locations of the merging credit union by street address, stating whether each location is to be closed or retained, and a list of branches of the continuing credit union by street address that are located in reasonable proximity to the merging credit union's locations."
12 CFR 708b.106(b)(6)And alongside it, the summary of the merger plan must carry "an explanation of any changes to ATM access or to services such as life savings protection insurance or loan protection insurance."
Source: 12 CFR 708b.106, via the Legal Information Institute.Read that as an IT requirement and it says something uncomfortable. Branch and service decisions have to be final, in writing, and correct, between 45 and 90 days before a vote that itself precedes the legal close. Whether a branch stays open depends on whether its staff can be served, its systems can be reached, and its members can be supported on day one. The rule does not mention technology anywhere. It asks for the branch decision, and the branch decision is downstream of a technology answer, which is why the technology work has to start first.
Members get 30 days to comment, and the comments are public
Within 30 calendar days of receiving that notice, members may submit comments about the merger to the NCUA, and the rule says plainly that "the NCUA will post these comments on a website accessible to credit union members." The agency reserves the right to withhold comments in seven specific categories, such as those that are false or misleading on a material fact, but the default is publication.
The practical effect is that the merger plan becomes a document members read closely and respond to in public. A branch list that changes after the notice goes out is not a quiet internal revision.
The vote, then two certification deadlines
Approval requires the affirmative vote of a majority of the members of the merging credit union who vote on the proposal. Members must be members as of the record date to vote, and the rule permits voting in person, by mail ballot, or electronically where the bylaws allow it.
After the vote, the board of the merging federal credit union certifies the results to the Regional Director within 10 days. The merger may be completed once the NCUA, the state supervisory authority where one is involved, and the members where required have all approved it. Then the board of the continuing credit union certifies completion to the Regional Director within 30 days after the effective date.
Source: 12 CFR 708b.106(g), 708b.107 and 708b.108, via the Legal Information Institute (708b.107, 708b.108).That last one matters more than it looks. The effective date is a legal fact with a certification attached to it. It is not a go-live window that slides when a migration runs long.
Which merger answers depend on a technology decision?
The merger notice reads like a member communications document. Underneath, several of its required disclosures cannot be written until someone has decided how the two Microsoft 365 environments will behave.
| What the member notice must say | The decision it silently depends on | Where that decision lives |
|---|---|---|
| Whether each merging credit union location is "to be closed or retained" | Can staff at that branch be reached, supported, and authenticated on day one, and can members be served there | Identity, device management, and network reachability in the continuing tenant |
| Which continuing credit union branches sit "in reasonable proximity" | Which of those branches will actually be able to serve inbound members without a second system | Core and Microsoft 365 access for staff who will absorb the volume |
| "Any changes to ATM access or to services" | Which member-facing services survive the cutover unchanged, and which change name, address, or behavior | The service inventory across both tenants |
| A summary of the merger plan, including the financial arrangements | Who keeps a mailbox, who does not, and for how long the source environment stays reachable | Licensing and retention decisions in both tenants |
| The statement of reasons for the merger | Whether the promised efficiencies depend on consolidation that has a real date attached | The integration plan the board is relying on |
The failure mode is not a late migration
A merger IT plan that starts after the member notice is not late in the ordinary sense. It is late in a way that cannot be recovered by adding people, because the answers were already published to members and filed with the NCUA.
The recoverable version of this problem is the one where the technology work starts before the notice is drafted, so the notice describes a plan that someone has confirmed is achievable.
Find out what your member notice will have to promise.
A tenant-merge planning workshop puts the statutory dates and the Microsoft prerequisites on one calendar, before the notice is drafted rather than after.
Book the workshopWhat does Microsoft require before a single mailbox moves?
Microsoft documents cross-tenant mailbox migration in detail, and the documentation is unusually blunt about what stops a move dead. Four of those conditions have long lead times.
A mailbox on hold does not move at all
"Mailboxes that are on any type of hold aren't migrated, and the move for those mailboxes is blocked."
Microsoft Learn, cross-tenant mailbox migrationFor most organizations that sentence is a footnote. For a credit union it is a planning item, because holds are exactly what a regulated institution accumulates: litigation holds, retention holds applied by policy, and holds placed during examinations or member disputes.
Finding them is work. Deciding what to do about each one is legal and compliance work, not IT work, and it has to happen early enough that the answer is not "we released a hold to make the migration run." The retention and archiving picture in the source tenant is the place that inventory starts.
The migration license is mandatory, and there are no exceptions
Cross-tenant migrations require a per user Cross-Tenant User Data Migration license, assignable on either the source or the target user object. Microsoft's own wording leaves no room:
"You must purchase, or verify you can purchase, cross-tenant user data migration licenses before the next steps. Migrations fail if this step isn't completed. Microsoft doesn't offer exceptions for this licensing requirement."
Microsoft Learn, cross-tenant mailbox migrationThis is a procurement action with a real number attached, scaled to headcount, and it belongs in the merger budget rather than in a surprise invoice during cutover week. It is also one of the items a planning workshop can size in an afternoon.
Every user has to exist in the destination before they can arrive
Microsoft requires that each migrating user already be present in the target tenant as a MailUser object carrying specific attributes copied from the source mailbox. Two of those attributes are described as absolute gates. On the archive identifier, Microsoft writes that "the move process doesn't proceed if this attribute isn't present on the target object." On the x500 addresses derived from the source LegacyExchangeDN, it writes that "the move process doesn't proceed if these x500 addresses aren't present on the target object."
Those x500 addresses are what let a reply to an old message still find the person after the move. Skip them and mail sent before the migration starts failing to deliver, which is the kind of defect members and examiners both notice.
- ExchangeGUID must match between the source mailbox and the target object, or a new empty mailbox is provisioned instead of a move.
- ArchiveGUID must match wherever the source mailbox has an archive, which in a credit union is most of them.
- Every x500 address from the source mailbox has to be copied across, not just the current one.
- A mail-enabled security group in the source tenant scopes which mailboxes are allowed to move, which is how the source side keeps the move from over-reaching.
A domain belongs to exactly one tenant
Microsoft states it flatly: "domains are associated with one Microsoft Entra ID or Exchange Online tenant only." The merging credit union's email domain cannot be live in both places at once, which makes the domain cutover a single dated event rather than a gradual transition, and makes the order of operations around it unforgiving.
This is also the step most visible to members, because it is the one that changes what appears in the from line of an email they receive.
Two things about Teams that people assume and should not
Meeting links do not survive the move intact. Microsoft says the meetings themselves are moved, but "the meeting URL isn't updated when items migrate cross-tenant. Since the URL is invalid in the target tenant, you must remove and recreate Teams meetings." Every recurring committee meeting, board meeting, and standing vendor call on the merging side has to be rebuilt.
Chat history does not come across either. Microsoft is explicit that the Teams chat folder content does not migrate cross-tenant, though after migration that content remains available for a source tenant administrator to search and export through a content search. For an institution with recordkeeping duties, that sentence is the difference between a gap and a documented export, and it only works while the source tenant still exists.
All quotations in this section: Microsoft Learn, cross-tenant mailbox migration.What has to be true on closing day?
Closing day is a legal fact with a 30 day certification attached to it. These are the conditions that have to already be satisfied when it arrives, because none of them can be arranged that morning. One item deliberately sits in the right-hand column rather than the left: the domain cutover can legitimately land before, on, or after the effective date. What has to be settled by closing day is which of those three it is, and whether members have been told.
Settled well before the date
- Every hold in the source tenant is inventoried, and each one has a documented decision from compliance rather than from IT
- Cross-Tenant User Data Migration licenses are purchased and assigned
- Target MailUser objects exist for every migrating person, with matching identifiers and full x500 history
- The organization relationship and migration endpoint are configured on both sides and tested
- The branch list in the member notice matches what the technology plan can actually deliver
Communicated, not discovered
- Recurring Teams meetings on the merging side will be recreated, so the calendar invitations staff already hold will stop working
- Teams chat history stays in the source tenant and has to be exported there while it still exists
- The domain cutover is a single dated event, so the day the from line changes is a day members should hear about in advance
- The source tenant has a retirement date of its own, and the records still living in it have to be dealt with before that date
How do you run the legal clock and the technical clock together?
The statutory windows do not move. What moves is when the technology work starts relative to them. This is the ordering that keeps the member notice honest.
Inventory both tenants while the merger plan is still being drafted
Holds, archives, licensing, domains, shared mailboxes, Teams estate, and the retention policies that touch any of them. This is the step that decides whether the later dates are achievable, and it is the one most often started after the notice instead of before it.
Decide branch and service outcomes, then write the notice around them
The rule requires the notice to state which locations close and which are retained, and to explain any changes to ATM access or member services. Those sentences should be the output of the technology plan, not a prediction the plan is then asked to satisfy.
Clear the long-lead Microsoft prerequisites during the notice window
The 45 to 90 days between the notice and the vote is not dead time. It is the natural window for resolving holds with compliance, purchasing migration licenses, and provisioning target objects, because none of those depend on the vote succeeding in the way later steps do.
Build and test the migration path before the vote, not after
The organization relationship, the migration endpoint, and a small pilot batch can all be proven while the vote is still pending. A pilot that finds a missing x500 address in week two costs an afternoon. The same discovery in cutover week costs the schedule.
Sequence the domain move against the legal effective date
A domain lives in one tenant. Decide deliberately whether the from line changes before, on, or after the effective date, tell members which it is, and make sure mail routing from the source side survives the gap either way.
Close the records loop before the source tenant is retired
Completion is certified to the Regional Director within 30 days of the effective date. The Teams chat content that stayed behind, the mailboxes converted to mail users, and anything held for litigation all still live in the source tenant on that day. Retiring it is a separate, later, deliberate decision with its own evidence trail.
A note on banks, and on which rule applies
Part 708b governs mergers of federally insured credit unions. A bank merger runs through a different approval path with its own agencies and its own notice requirements, so the statutory dates on this page should not be applied to one. The Microsoft prerequisites in the middle of this page are the same either way, because they are properties of the platform rather than of the charter.
For the migration mechanics themselves, including cutover versus coexistence and the five phase sequence, see our companion article on Microsoft 365 tenant-to-tenant migration for credit union and bank mergers.
A free tenant-merge planning workshop, sized to the notice date
Put both clocks on one calendar before the member notice is drafted.
Access Business Technologies is a Tier 1 Microsoft Cloud Solution Provider working with credit unions, banks, and mortgage companies. We manage Microsoft 365 tenants and we host Azure environments, which means the two environments in a merger are the kind of thing we look at every week.
- A hold and retention inventory across both tenants, so the mailboxes that Microsoft will refuse to move are known before they block anything.
- A migration licensing count, so the per user requirement is a budget line rather than a cutover week surprise.
- A branch and service readiness read, mapped to the disclosures the member notice is required to contain.
- One calendar carrying the statutory dates and the technical lead times together, with the collision points marked.
- A records position for the source tenant, covering what stays behind, how it gets exported, and when the environment can responsibly be retired.
ABT also operates M365 Guardian, its managed security service for credit unions, banks, and mortgage companies.
Where the facts on this page come from
Every date, quotation, and figure on this page was taken from the issuing body rather than from secondary coverage, and checked on the day this page was published.
- 12 CFR Part 708b, Mergers of Federally Insured Credit Unions. The statutory windows, the member notice contents, the comment window, the vote threshold, and both certification deadlines. Text retrieved from the Electronic Code of Federal Regulations and linked here through the Legal Information Institute, which reproduces the same rule text. Sections cited: 708b.103, 708b.104, 708b.106, 708b.107, 708b.108.
- Microsoft Learn, cross-tenant mailbox migration. The hold restriction, the licensing requirement, the target object prerequisites, the single tenant per domain rule, and the Teams behavior. Read the Microsoft documentation.
- NCUA, first quarter 2026 credit union system performance data. The count of federally insured credit unions and the year over year comparison. Read the NCUA release. The decline of 161 institutions is arithmetic on the two figures NCUA published, not a figure NCUA stated.
Regulations change. If you are planning a merger, confirm the current rule text against the source before relying on any date, including the ones on this page.
Related reading
Microsoft 365 Tenant-to-Tenant Migration for Credit Union and Bank Mergers
This page covers the when. That article covers the how: cutover versus coexistence, identity first, and the five phase sequence.
Microsoft 365 Data Retention for Financial Institutions
Where the hold inventory starts, and why the policies already running in your tenant decide which mailboxes Microsoft will refuse to move.
Credit Union Board IT Reporting: What NCUA and FFIEC Examiners Expect
The reporting rhythm a merging board needs anyway, and the one that makes the 24 month board minutes requirement painless.
A related risk: could you actually recover this data?
A merger concentrates two institutions' records into one tenant. That makes recoverability a question worth answering before the consolidation, not after it.
If a ransomware crew encrypted your Microsoft 365 environment tomorrow, what could you actually restore, and how fast?
Credit union merger IT timeline questions, answered from the rule text
Members of the merging credit union must receive written notice at least 45 calendar days, but no more than 90 calendar days, before any member meeting called to vote on the merger proposal. That is 12 CFR 708b.106(a), and it is both a floor and a ceiling, so the notice cannot be sent unusually early to buy time either.
Yes. 12 CFR 708b.106(b)(6) requires the notice to contain a statement identifying the physical locations of the merging credit union by street address, stating whether each location is to be closed or retained, along with a list of the continuing credit union's branches by street address that are located in reasonable proximity. The same notice must also explain any changes to ATM access or to services such as life savings protection insurance or loan protection insurance. This is why merger IT planning cannot start after the notice. Whether a branch can be retained depends on whether its people and systems can be served on day one, and that answer has to exist before the notice is written.
Yes to both. Under 12 CFR 708b.106(d), members may jointly or individually submit a comment about the merger to the NCUA within 30 calendar days of receiving the notice, and the NCUA will post those comments on a website accessible to credit union members. The NCUA reserves the right to withhold comments in seven listed categories, including those that are false or misleading with respect to a material fact or that relate to a personal grievance, but publication is the default.
The most common blocker in a regulated institution is a hold. Microsoft states that mailboxes on any type of hold are not migrated and that the move for those mailboxes is blocked. The second is licensing: cross-tenant migration requires a per user Cross-Tenant User Data Migration license, and Microsoft says migrations fail without it and that it does not offer exceptions to that requirement. The third is the target object. Each migrating user has to already exist in the destination tenant as a MailUser with a matching ExchangeGUID, a matching ArchiveGUID where the source mailbox has an archive, and the source LegacyExchangeDN carried across as an x500 address. Microsoft states that the move process does not proceed when the archive identifier or the x500 addresses are missing from the target object.
Both domains can continue to exist, but not in both tenants. Microsoft states that domains are associated with one Microsoft Entra ID or Exchange Online tenant only. That makes the domain move a single dated event rather than a gradual transition, and it is the step members notice most directly, because it changes what appears in the from line of the email they receive.
Partly. Microsoft states that Teams meetings are moved but the meeting URL is not updated, that the URL is invalid in the target tenant, and that you must remove and recreate Teams meetings. Every recurring board, committee, and vendor meeting on the merging side has to be rebuilt. Teams chat folder content does not migrate cross-tenant at all. Microsoft notes that after migration it remains available for a source tenant administrator to search and export using a content search, which means the export has to happen while the source tenant still exists.
Twice, on two different clocks. Under 12 CFR 708b.107 the board of the merging federal credit union must certify the results of the membership vote to the Regional Director within 10 days after the vote is taken. Under 12 CFR 708b.108(b), the board of the continuing credit union must certify completion of the merger to the Regional Director within 30 days after the effective date. The effective date is therefore a fixed legal fact with paperwork attached, which is why it does not behave like a go-live date that can slip when a migration runs long.
Twenty four months. Under 12 CFR 708b.104(a)(10) the submission to the Regional Director must include board minutes for both the merging and the continuing credit union that reference the merger for the 24 months before the date the boards of directors of both credit unions approved the merger plan. That is a records retrieval exercise, and it is considerably easier at an institution whose board reporting was already organized and searchable before the merger conversation started.
The statutory dates do not. 12 CFR Part 708b governs mergers of federally insured credit unions specifically, and a bank merger runs through a different approval path with different agencies and different notice requirements. The Microsoft prerequisites described here do apply, because they are properties of Microsoft 365 rather than of the charter. Holds still block mailbox moves, the migration licensing requirement still has no exceptions, target objects still have to be provisioned in advance, and a domain still belongs to exactly one tenant.
Plan the tenant merge
before the notice goes out.
Tell us roughly how many people are in each institution and where you are in the merger process. Our engineers will inventory the holds and retention policies that block mailbox moves, count the migration licenses the move will need, and put the statutory dates and the technical lead times on one calendar.
