The week before cutover is when offices either create a usable recovery point or create a false sense of safety. A full disk image of the old server is useful, and it is not enough. After a migration, the question you will actually ask is not "do we have a backup." The question is whether you can restore the specific thing that is missing: the share folder someone cannot find, the scheduled task that stopped emailing a vendor, the user list that still has the right group memberships, or the config file that told the scanner where to write. Backing up the week before cutover means capturing those restore targets on purpose.
Treat the pre-cutover backup as its own short project with a written checklist and a person who signs off that each item landed somewhere restorable. Do this while the old server is still the live system. A backup taken after people have already started working on the new tools is a different artifact, and it will not answer questions about the state of the office on the Friday before you flipped.
Capture the live workloads, not just the disks
Start with the file share in a form you can browse later without rebuilding the whole server. A full image is fine as a last resort. A file-level copy of the share to an offline disk or a cold bucket is what you will reach for when someone asks for a folder from a closed matter. Take that copy after the final pre-freeze sync of the active folders, and label it with the date and the freeze window it corresponds to. If you take the share backup too early, the delta between backup and cutover becomes a second recovery problem.
Export the permission model with the files. An ACL that lived in Active Directory and NTFS will not travel inside a naive file copy the way people expect. Capture group memberships for the security groups that gate the share, and keep a written map of which groups had rights to which top-level folders. When a restore is needed six months later, you will care as much about who should see the folder as about the PDFs inside it.
Back up the identity pieces the office still depends on during the overlap. That usually means a system state backup of the domain controller role if one still lives on the office server, plus an export of DHCP reservations, DNS records that point at the server, and any local accounts that applications still use. Migrations that move files and apps but leave login services half-migrated are common. The backup of identity is what lets you reverse a bad weekend without guessing passwords from a sticky note drawer.
Scheduled tasks, configs, and the quiet writers
Scheduled tasks deserve their own backup package. Export the Task Scheduler library, including the credentials context each task runs under if your process allows it, and keep a copy of the scripts and working directories those tasks call. A task definition without the script it launches is theater. A script without the config file that holds the vendor path is the same. Put the task XML, the scripts, and the small config files into one dated folder so a future restore is not a scavenger hunt across three locations.
Capture application configs the same way. Accounting packages, document management clients, time-and-billing tools, and the odd Access front end all store paths and connection strings somewhere. Copy those config files and take screenshots of the settings screens where the path is only in a UI. Note the service accounts. Note the ODBC DSNs. Note the printer mappings that matter for the one department that still prints settlement packages to a specific tray. This is unglamorous work and it is the difference between a two-hour restore and a two-day reconstruction.
Do not forget the writers that are not people. The multifunction scanner's address book, the fax-to-folder destination, the backup agent's own job definitions, and any vendor SFTP drops that land on the share overnight. Each of these is a config that will still try to write to the old path after cutover unless you change it, and each is also something you may need to recreate if the new path is wrong. Back up the config, then use that same list as the cutover change list. The backup and the migration checklist should describe the same set of objects.
Prove the backup before you need it
A backup that has never been restored is a rumor. In the week before cutover, restore one sample from each class of backup to a location that is not production. Open a handful of files from the share copy. Confirm a scheduled task export can be re-imported on a throwaway machine or at least that the XML is complete and readable. Confirm that the config folder contains the files you think it contains by opening them, not by trusting the copy log. This takes a few hours and prevents the worst version of cutover week, which is discovering on Monday that the backup job wrote empty folders because a credential expired on Thursday.
Write down where each backup lives, who can access it, and how long it will be kept. Cold storage that only one contractor can unlock is not a firm asset. Put the locations in the same migration document that holds the workload list and the cutover dates. When the old server is powered down, that document is what remains of institutional memory.
Decide in writing what the backup is for. The pre-cutover package is primarily a rollback and reference set for the migration window and the first months after. It is not a substitute for the ongoing backup regime on the new systems. The new file platform needs its own retention. The new SaaS tools need their own export habits. Mixing those jobs in one sentence is how offices keep an old server image forever and still cannot reconstruct last month's work from the new stack.
The short list that usually matters
For a typical office retiring a closet server, the week-before package that earns its keep is a dated file-level copy of the share, the permission and group map, identity and DNS exports if those still live on the box, the scheduled task package with scripts and configs, application config files and settings screenshots, and the list of non-human writers with their destinations. Add a full server image if you have the space and the time, and treat it as the secondary artifact, not the primary one.
Sign off each item with a name and a timestamp. Then proceed with cutover knowing that a missed folder or a broken task is recoverable from a known point rather than from memory. The migration is a written project with a date. The backup the week before is the same kind of project, smaller and earlier, and it is what makes the decommission date something you can keep.