When is the best time to cut over a Microsoft 365 migration at a financial services firm?

Inside a quiet stretch of the close calendar, not on a date chosen for technical convenience. For a firm on a calendar fiscal year, the usable stretches are typically the back half of a non-quarter-end month, and in practice the two longest are late spring after the year-end audit clears and late summer between the second and third quarter closes. Your exact dates depend on your fiscal year, your reporting deadlines and when your audit firm books fieldwork — but the shape holds: a handful of workable fortnights a year, not an open calendar. Establish those windows before the project plan is drawn, because everything else in the plan can move and they cannot.

Why can't we migrate mailboxes during month-end close?

Because a large share of the evidence supporting a close lives in mail and collaboration systems, not in the ledger. Journal-entry approvals, accrual sign-offs, reconciliation reviews, wire authorizations, custodian and bank confirmations, vendor statements and the auditor's document requests are routinely transacted by email, shared mailbox or Teams message. Moving those mailboxes while an approval is in flight puts one half of an approval chain on one side of a cutover and the other half on the other side. The ledger itself may be untouched by the migration and the close still breaks.

Which systems should never move in the middle of a reporting period?

Anything that touches the ledger, the reporting pipeline or the audit trail. In practice that means the mailboxes and shared mailboxes of the close and treasury teams; distribution groups and shared mailboxes that receive bank, custodian or invoice feeds; the sites holding the close binder, reconciliation workpapers and the auditor's requested documents; the service accounts and application registrations that let finance systems authenticate, send scheduled reports or write files; and the retention, hold and logging configuration that determines what can later be produced. The common thread is that these fail silently — nothing errors until the month-end job runs.

What do auditors ask about administrative access during a migration?

The recurring question is who held administrative access to the environment during the period under review, what they could do with it, and how you know. A migration answers that question badly if access was granted as a shared account, an unscoped role or an open-ended grant, because the answer then has to be reconstructed from memory. It answers well if each engineer worked under a named account in the firm's own tenant, with roles scoped to the task, an agreed start and end date, and every action attributable in the tenant's own audit log. The difference is entirely in whether the access was designed before it was granted.

Should a migration vendor be given Global Administrator rights?

Not by default, and not open-ended. Tenant-wide administrative rights held for weeks by an outside party is exactly the fact pattern that reads badly in a control review, because a person with those rights can in principle alter the group membership that governs approvals, read an approver's mailbox, or change logging configuration. The workable pattern is least privilege to the workload the wave actually touches, elevated only where a specific task genuinely requires it, time-boxed to the wave, granted and revoked by the client rather than self-provisioned, and logged. Where the firm runs a just-in-time privileged access process, engineering access should run through it like anyone else's.

How does segregation of duties apply to an IT migration project?

The principle is that the person who can make a change should not also be the only person who can approve it or review the record of it. On a migration that means the engineering team performing changes should not be the sole reader of the audit log that records them, should not be the party that attests membership of finance approval groups after a rebuild, and should not hold rights that let it modify the logging or retention configuration covering its own work. The mitigation is unglamorous: the firm keeps log review and group attestation with someone outside the project, and the project produces a written record of access rather than the firm having to derive one.

When should the source environment be decommissioned after a migration?

After the periods it covers have been closed and audited, not when the project finishes. Decommissioning is a calendar decision that belongs to the controller and the compliance officer, not a task that falls out of a project plan. Until that point the source has to remain readable, with retention and holds intact, and with someone at the firm — not only the vendor — able to run a search and export the results. Deleting a mailbox, expiring an archive or removing a hold before the relevant audit is complete is the one migration mistake that cannot be undone.

Do SOC 2, PCI DSS and GLBA change how a migration should be planned?

Each is an obligation the firm is subject to, and each touches a migration in a different place. A SOC 2 examination covers a period, so a project that runs inside that period sits inside the report's window — the access, change and logging story has to hold for the whole window, not just look tidy at the end. PCI DSS applies only where cardholder data is in scope, so the migration's job is to confirm the boundary in writing beforehand and treat any workload that turns out to touch card data as a scope change rather than a detail. The GLBA Safeguards Rule bears most directly on access to customer information and on the firm's oversight of its service providers, which is precisely why named, time-boxed, logged engineering access is what makes that oversight demonstrable.

Does Pro IT NW audit controls or issue a compliance opinion?

No. We do not perform audits, issue attestations, or sign off on the design or operating effectiveness of controls, and we hold no certification or report of our own. Those roles belong to an independent audit firm, and mixing them with the engineering role creates a conflict a reviewer will flag. What we do is engineer the migration inside the constraints the firm's obligations create, and hand back written evidence of what was done, by whom, under what access, and when that access ended.

Field notes · 15 min read · August 19, 2026

The close cycle sets your migration calendar

The close calendar is the constraint, and it was fixed before your project plan existed. Month-end, quarter-end, year-end and audit fieldwork remove most of the year as cutover time. Pick the window first, then fit the waves to it — not the other way round.

You have been handed a migration date. Someone else picked it — a lease expiry, a board commitment, an acquisition close, an engineer's availability — and it lands on the fourteenth of the month, two weeks before quarter-end. Around the table it reads as a technical question, and the technical answer is yes: the mailboxes will move, the identities will cut over, the tooling is fine.

It is not a technical question. In a financial services organization the close cycle sets the migration calendar, and the close cycle was fixed long before anyone opened the project plan. Most plans we are asked to review were drawn the other way round — waves first, dates second, close calendar consulted at the end if at all. This is the argument for inverting that, and the specifics of what it changes.

The one-sentence version: pick the cutover window out of the close calendar first, then fit the waves to it — and design the administrative access the project needs as an audit artifact before it is granted, because your auditor is going to ask who held it during the period.

Work out the year: what is actually left

Do the arithmetic before you argue about tooling. Take a firm on a calendar fiscal year and mark the immovable blocks:

Month-end close. Roughly the first working week to ten days of every month are gone. The finance team is at capacity, and the systems the close runs through are the ones a migration touches.
Quarter-end close. Longer than a month-end, and followed by reporting deadlines that are external and dated. The month containing a quarter-end is effectively unavailable end to end.
Year-end close and the annual report. The first weeks of the new year, plus whatever tail the reporting timetable adds.
External audit fieldwork. The one you control least. Fieldwork dates are set by the audit firm's capacity, they move, and they can extend. Treat fieldwork as a block whose edges you cannot pin down, which means leaving margin on both sides rather than butting a cutover against its planned end date.
Examination and regulatory reporting cycles, if you are a federally insured institution or regulated in a state that runs its own examination calendar. These land on top of the close calendar, not instead of it.

Lay those on a year and the shape is stark. January through roughly April is year-end close running into fieldwork running into the first-quarter close. July is the second-quarter close. October is the third. November and December carry budget season, year-end preparation and, in a lot of firms, a change freeze that starts earlier than anyone outside finance expects. What survives is the back half of the ordinary months, and two genuinely usable stretches: late spring, once the year-end audit has cleared, and late summer, between the second and third quarter closes.

Your dates will differ — a June or September fiscal year moves everything, and a firm with a fast close has more room than one still closing on day twelve. The shape does not. A financial services firm has a handful of workable fortnights a year for an irreversible cutover, not an open calendar with a few bad weeks in it. That is the number the project plan has to be built around, and it is the number that is almost never established first.

The inversion, stated plainly: do not draw waves and then look for a window. Establish the windows with the controller, then decide how much migration fits inside one. If the answer is "less than the whole migration", you have learned the real shape of the project — a sequence of small, reversible moves punctuated by two or three genuine cutovers — rather than discovering it at quarter-end.

What cannot move mid-period, and why

The instinct is to protect the ledger and treat everything else as ordinary IT. That is the wrong boundary. The general ledger is usually not what a Microsoft 365 migration touches at all — and the close still breaks, because a large part of the evidence supporting the ledger does not live in the ledger.

The close team's mailboxes. Journal-entry approvals, accrual sign-offs, reconciliation reviews and wire authorizations are routinely transacted and evidenced in mail. Move a mailbox with an approval in flight and you have split one control across a cutover boundary.
Shared mailboxes and distribution groups that are really integration endpoints. Bank and custodian files, invoice feeds, vendor confirmations and statement deliveries arrive at addresses nobody thinks of as a system. They are a system. Changing where they deliver, or who can read them, is a change to a data feed.
The sites holding the close binder and the workpapers, including whatever list of documents the auditors are currently working through. Permissions on those sites are part of the control, not a convenience.
Service accounts and application registrations. The reporting tool that mails the board pack, the reconciliation platform that authenticates through the directory, the scheduled export that writes a file somewhere. These fail silently. Nothing errors on the day you change authentication; it errors on the day the month-end job runs, which is the worst possible day to find out.
Retention, hold and logging configuration. This determines what can later be produced and for how long. It is the least visible thing in a migration and the most consequential to an audit.

A useful test when a stakeholder insists an item is low risk: ask what would tell you it had broken, and how long that would take. If the honest answer is "the close", it does not move mid-period. The Microsoft 365 migration mechanics are the same as anywhere; what is different in finance is that the failure signal arrives weeks late and lands on someone with a filing deadline.

The evidence problem: a migration moves where the record lives

An audit asks a firm to produce evidence about a past period. A migration changes, mid-story, where that evidence lives and who is able to produce it. Three distinct things can go wrong, and they need separating because the fixes differ.

Location. The evidence for the period was created in the old environment; by the time the question is asked, the firm runs the new one. Somebody has to be able to get at it, in readable form, with its metadata intact.
Continuity of the record. Retention policies and legal holds are configured per environment and per workload. A move can quietly reset them. Holds have to be established on the destination and verified before anything is removed from the source, not after — the ordering is the whole control.
Producibility. This is the one that gets missed. If the only person who can run a search across the audit period is an engineer whose access ended when the project closed, the firm does not have a technical problem, it has an evidence problem. Somebody employed by the firm must be able to produce the record without calling the vendor.

And then the question that reframes the whole engagement: auditors ask who had administrative access during the period. A migration is, by construction, a period during which people who do not normally hold administrative rights hold them. That is answerable, and answerable well — but only if the answer was built in advance. Reconstructed afterwards it turns into the familiar mess: a shared credential, a break-glass account three people used, an account created for a wave in March that is still enabled in November and nobody is quite sure what it did.

Administrative access is an audit artifact, not a convenience

This is the part we would ask you to hold any vendor to, including us. Access granted for a project is evidence in a future audit. Design it that way before it exists.

Named accounts, one per engineer, never shared. A shared consultant account destroys attribution permanently and cannot be repaired later. If two people can sign in as the same identity, no log in the world will tell you which of them made a change.
Created, assigned and revoked by the client. We ask for access; we do not provision our own. The firm keeps the ability to end it in one action, at any moment, without our cooperation.
Time-boxed to the wave. A start date and an end date agreed in writing before the account exists, tied to the work it is for. Standing access with no expiry is the default that causes the November problem above.
Scoped to the workload, not to the tenant. Least privilege for the task the wave actually requires, with broader rights elevated only where a specific step genuinely needs them, and dropped again after. Where the firm runs a just-in-time privileged access process with justification and approval, engineering access goes through it like everyone else's.
Attributable in the tenant's own audit log. Not our ticketing system. Our records are a convenience; the firm's log is the artifact. If the two ever disagree, the firm's log is the one that counts.
Readable by the client, unaided. This is the test that matters. If answering "who did what in our environment during the third quarter" requires a request to the vendor, the control is not in the firm's hands. It should be a query the firm's own team can run and export.
Closed out in writing. At the end of the engagement, a document listing every account created, the roles it held, when it was activated and when it was removed. The controller drops it in the audit file instead of re-deriving it a year later.

None of that is exotic engineering. It is ordinary privileged-access hygiene, applied to the vendor rather than only to staff — the same tiering discipline we describe in AD Tier-0 in 90 days, and the same identity groundwork that an Active Directory audit puts on paper before a project starts. What makes it a differentiator is how rarely it is offered before it is asked for. Ask for it explicitly, in the statement of work, of whoever you hire.

Segregation of duties during a project

Segregation of duties says the person who can initiate something should not also be the person who approves it or the only person who can see the record of it. Projects are where that quietly collapses, because a project needs speed and speed wants one person with all the rights.

Consider what broad tenant rights held for six weeks across a close actually confer. The holder could, in principle, change the group membership that governs who approves a payment; read the mailbox of an approver; alter or disable the logging that would record either; grant themselves access to a finance site. Nobody is alleging that anybody did. The point is that the auditor's question is not "did you" — it is "could you, and would anyone have known?" An engagement that leaves the honest answer as "yes, and no" has created a finding out of a clean piece of work.

Four things break specifically, and each has a plain mitigation:

Shared or break-glass accounts used by the project team. Attribution is gone. Mitigation: named accounts, and break-glass reserved for its actual purpose with alerting on use.
The party making changes is also the only party reading the log of them. Mitigation: log review stays with someone at the firm outside the project, for the duration of the project.
Approval groups rewritten during a rebuild. Moving or reconstructing groups can silently change who sits in an approver population. Mitigation: export finance-relevant group membership before the wave, have the controller attest it, and have the controller re-attest after — the engineer confirming their own work is not a control.
Temporary elevation that outlives the task. Mitigation: the expiry date exists before the access does, and someone at the firm owns checking it.

The firm's own staff have the same exposure, incidentally. The admin who performs a change and also writes the evidence of it is a single point of trust, project or no project. Independent review by someone outside the work is the whole of the fix, and it is cheap. Our identity, security and compliance work is normally where this gets designed, and our methodology is built around handing the keys back rather than keeping them.

Sequencing: what goes in the quiet fortnight, and what waits

Once the windows are fixed, sequencing follows from one question: if this step failed, would the close see it, and how quickly? Rank by blast radius and by how silent the failure is.

Into the quiet fortnight — the irreversible, high-blast-radius steps:

The cutover itself for the close, treasury and reporting populations.
Mail routing changes, and anything that alters where an inbound feed lands.
Authentication changes for finance-adjacent applications — the sign-on integrations for the ERP, the reconciliation platform, the custodian portal.
Service accounts and application registrations behind scheduled jobs, with a deliberate test of a month-end run rather than a wait-and-see.
Any step that removes the rollback path.

Outside the window — reversible, invisible to the ledger:

Discovery and inventory: which workloads, which mailboxes, which integrations, which service accounts.
Building the destination — configuration, policy baselines, group structure, and retention and hold configuration established and verified before anything depends on it.
Pilot waves on populations whose failure is survivable. Finance is never the pilot group, and the temptation to use it because "they are organized and they will tell us" should be resisted.
Communications, training, and getting people enrolled in whatever authentication they will need on the day.
Cleanup that does not remove a rollback path.

Waits until after the close and after fieldwork:

Decommissioning the source. Deleting mailboxes. Expiring archives. Removing holds. Changing retention.
Anything that reduces what can be queried about a period that has not yet been audited.

That last block deserves stating on its own, because it is the one irreversible category: the source stays readable until the periods it covers have been audited. Decommissioning is a calendar decision owned by the controller and the compliance officer. It is not a project task, it does not belong on the critical path, and a project that treats "old environment retired" as its definition of done will pressure someone into deleting evidence to close a ticket.

One more sequencing point that is easy to miss: coexistence is a state, and during a close it is the risky one. A phased migration means weeks where mail, calendars, shared mailbox access and group delivery span two environments. Free/busy lookups are wrong, a shared mailbox is reachable from one side only, a distribution group delivers to half its members. Aim to be wholly on one side of that boundary during a close, not partway across it. Being stable matters more than being fast, and a wave that would land the close team in coexistence over month-end should be split or deferred rather than accelerated.

Where SOC 2, PCI DSS and GLBA actually bite

These are obligations your firm is subject to. They are not credentials a vendor holds, and any vendor implying otherwise is telling you something about the rest of their claims. Each one touches a migration plan in a different, specific place — and being precise about where saves a great deal of theatre.

SOC 2. If you issue a report to your own customers, an examination covers a period. A project that runs inside that period is inside the report's window, which means the access story, the change story and the logging story have to hold for the whole window rather than merely look tidy on the last day. That is the practical bite: a migration is a concentration of privileged access and changes dropped into the middle of an observation period. The scope of the report, the criteria selected and the opinion itself belong to your firm and your independent audit firm — not to your engineers, and not to us.
PCI DSS. It applies where cardholder data is in scope, and for most Microsoft 365 migration work the honest answer is that it should be out of scope and the plan's job is to keep it that way. The bite is at the boundary: confirm in writing, before the wave, which systems are in and out; and treat the discovery that a migrated workload receives or stores card data — a mailbox taking card numbers by email is the classic accident — as a scope change to be escalated, not a detail to be handled quietly. "We do not take cards" is worth testing rather than assuming, because a payment portal that mails receipts can surprise a controller.
GLBA Safeguards Rule. Of the three, this is the one that bears most directly on how a migration is run. It is about protecting customer non-public personal information, and two of its concerns land squarely on the project: who has access to customer information — which now includes engineering access you are about to grant — and your oversight of the service providers you use. That second one is worth reading twice, because it is your obligation, not ours. Named, scoped, time-boxed, logged access is not merely good hygiene here; it is the thing that makes your oversight of a vendor demonstrable rather than assertable.

What none of them do is turn an engineering firm into an assessor. We do not perform audits, issue attestations or opine on control effectiveness, and we hold no report of our own to wave at you. We engineer inside the constraints your obligations create and hand you written evidence of what was done. The financial services practice page sets out where that line sits and what is explicitly excluded from scope.

What to do with a date that lands in quarter-end

Assume you cannot simply refuse it. The move is not to argue about the date in the abstract; it is to make the constraint visible and let the date change itself. Concretely, in this order:

Get the close calendar on paper, from the controller, for the next twelve months. Month-end cadence, quarter-end reporting deadlines, year-end, fieldwork as currently booked, examination cycles, and the change freeze. This takes one conversation and it is the single highest-leverage hour in the project.
Mark the two or three windows, and be honest about their real length after margin on both sides of fieldwork.
Split the work into what needs a window and what does not. Most of a migration does not. The part that does is usually smaller than the plan implies, which is what makes the conversation winnable.
Design the access before you ask for it. Named accounts, scopes, dates, who grants, who revokes, where the log is and who at the firm can read it — written down before anyone signs in.
Put the decommission date under the controller's name, separated from project completion and dependent on the audit, not on the plan.
Take that back to whoever set the date. "The cutover has to be in the fortnight starting X" is a much easier sentence to defend when it arrives with the calendar attached and the rest of the project already moving.

The 30-second version

In a financial services firm the close cycle, not the technology, sets the migration calendar. Month-end, quarter-end, year-end and audit fieldwork remove most of the year, leaving a handful of workable fortnights for an irreversible cutover. Anything touching the ledger, the reporting pipeline or the audit trail stays put mid-period — including the mailboxes, shared mailboxes, sites and service accounts where the evidence supporting the close actually lives. A migration also changes where audit evidence lives and who can produce it, so holds go on the destination before anything leaves the source, and the source stays readable until the periods it covers are audited. Auditors ask who held administrative access during the period: grant it as named, scoped, time-boxed accounts, created and revoked by the firm, attributable in the firm's own audit log, readable by the firm without asking the vendor, and closed out in writing. Keep log review and group attestation with someone outside the project. Then sequence: the irreversible steps go in the quiet fortnight, everything reversible goes outside it, and decommissioning waits for the audit.

If you have a date that lands in quarter-end and want a second opinion on what actually has to happen inside it, the project intake form takes about three minutes. Tell us the institution type, the seat count and the date you were given.

Pro IT NW is a labor-only, vendor-neutral Microsoft 365 and identity consultancy working with mid-market financial services firms. We do not resell licensing, perform audits, or issue attestations of any kind — those belong to your independent audit firm. Nothing here is legal, accounting or audit advice; scope questions about SOC 2, PCI DSS or GLBA belong with your auditor and your compliance officer.

Questions we get asked

When is the best time to cut over a Microsoft 365 migration at a financial services firm?: Inside a quiet stretch of the close calendar, not on a date chosen for technical convenience. For a firm on a calendar fiscal year, the usable stretches are typically the back half of a non-quarter-end month, and in practice the two longest are late spring after the year-end audit clears and late summer between the second and third quarter closes. Your exact dates depend on your fiscal year, your reporting deadlines and when your audit firm books fieldwork — but the shape holds: a handful of workable fortnights a year, not an open calendar. Establish those windows before the project plan is drawn, because everything else in the plan can move and they cannot.
Why can't we migrate mailboxes during month-end close?: Because a large share of the evidence supporting a close lives in mail and collaboration systems, not in the ledger. Journal-entry approvals, accrual sign-offs, reconciliation reviews, wire authorizations, custodian and bank confirmations, vendor statements and the auditor's document requests are routinely transacted by email, shared mailbox or Teams message. Moving those mailboxes while an approval is in flight puts one half of an approval chain on one side of a cutover and the other half on the other side. The ledger itself may be untouched by the migration and the close still breaks.
Which systems should never move in the middle of a reporting period?: Anything that touches the ledger, the reporting pipeline or the audit trail. In practice that means the mailboxes and shared mailboxes of the close and treasury teams; distribution groups and shared mailboxes that receive bank, custodian or invoice feeds; the sites holding the close binder, reconciliation workpapers and the auditor's requested documents; the service accounts and application registrations that let finance systems authenticate, send scheduled reports or write files; and the retention, hold and logging configuration that determines what can later be produced. The common thread is that these fail silently — nothing errors until the month-end job runs.
What do auditors ask about administrative access during a migration?: The recurring question is who held administrative access to the environment during the period under review, what they could do with it, and how you know. A migration answers that question badly if access was granted as a shared account, an unscoped role or an open-ended grant, because the answer then has to be reconstructed from memory. It answers well if each engineer worked under a named account in the firm's own tenant, with roles scoped to the task, an agreed start and end date, and every action attributable in the tenant's own audit log. The difference is entirely in whether the access was designed before it was granted.
Should a migration vendor be given Global Administrator rights?: Not by default, and not open-ended. Tenant-wide administrative rights held for weeks by an outside party is exactly the fact pattern that reads badly in a control review, because a person with those rights can in principle alter the group membership that governs approvals, read an approver's mailbox, or change logging configuration. The workable pattern is least privilege to the workload the wave actually touches, elevated only where a specific task genuinely requires it, time-boxed to the wave, granted and revoked by the client rather than self-provisioned, and logged. Where the firm runs a just-in-time privileged access process, engineering access should run through it like anyone else's.
How does segregation of duties apply to an IT migration project?: The principle is that the person who can make a change should not also be the only person who can approve it or review the record of it. On a migration that means the engineering team performing changes should not be the sole reader of the audit log that records them, should not be the party that attests membership of finance approval groups after a rebuild, and should not hold rights that let it modify the logging or retention configuration covering its own work. The mitigation is unglamorous: the firm keeps log review and group attestation with someone outside the project, and the project produces a written record of access rather than the firm having to derive one.
When should the source environment be decommissioned after a migration?: After the periods it covers have been closed and audited, not when the project finishes. Decommissioning is a calendar decision that belongs to the controller and the compliance officer, not a task that falls out of a project plan. Until that point the source has to remain readable, with retention and holds intact, and with someone at the firm — not only the vendor — able to run a search and export the results. Deleting a mailbox, expiring an archive or removing a hold before the relevant audit is complete is the one migration mistake that cannot be undone.
Do SOC 2, PCI DSS and GLBA change how a migration should be planned?: Each is an obligation the firm is subject to, and each touches a migration in a different place. A SOC 2 examination covers a period, so a project that runs inside that period sits inside the report's window — the access, change and logging story has to hold for the whole window, not just look tidy at the end. PCI DSS applies only where cardholder data is in scope, so the migration's job is to confirm the boundary in writing beforehand and treat any workload that turns out to touch card data as a scope change rather than a detail. The GLBA Safeguards Rule bears most directly on access to customer information and on the firm's oversight of its service providers, which is precisely why named, time-boxed, logged engineering access is what makes that oversight demonstrable.
Does Pro IT NW audit controls or issue a compliance opinion?: No. We do not perform audits, issue attestations, or sign off on the design or operating effectiveness of controls, and we hold no certification or report of our own. Those roles belong to an independent audit firm, and mixing them with the engineering role creates a conflict a reviewer will flag. What we do is engineer the migration inside the constraints the firm's obligations create, and hand back written evidence of what was done, by whom, under what access, and when that access ended.

Related service

Financial services IT

Written by the team at Pro IT NW · Senior-led Microsoft project consultancy · Seattle / USA-wide.

Share on LinkedIn Follow Pro IT NW