Microsoft has set a hard deadline: October 1, 2026, marks the end of support for the SharePoint Migration Assessment Tool (SMAT), pushing SharePoint farm administrators to adopt the built-in scanning capabilities of SharePoint Migration Tool (SPMT) version 4.0 or later. With just over two months left, organizations that rely on SMAT’s customizable reports must decide whether to run one final baseline or cut over to the newer tool immediately.

What SMAT Brought to the Table

For years, SMAT was the go-to command-line scanner for SharePoint 2010, 2013, and 2016 farms. Running as the farm service account, it crawled web applications and user profile services without impacting production performance—though a complete scan often took one to two days. Its output landed in a Logs directory, giving admins a detailed inventory of sites, lists, and potential migration blockers.

Two configuration files gave SMAT its power and its pitfalls. ScanDef.json could enable or disable individual scans; admins often turned off checks they deemed irrelevant, speeding up runs and silencing noise. SiteSkipList.csv excluded specific site collections from reports, letting organizations filter out test sites or deprecated portals. While these options made SMAT flexible, they also embedded assumptions that become dangerous if forgotten.

SPMT 4.0: More Than Just a Scanner

Microsoft now directs everyone to SPMT’s scan feature, which bakes assessment directly into the migration workflow. Instead of a standalone executable and a folder of logs, SPMT presents a dashboard with site-content inventory and migration-risk summaries. You can scan single sites for validation or use bulk scanning for larger scopes, then download detailed reports for remediation tracking.

The shift isn’t just cosmetic. SPMT bridges discovery and execution: after reviewing scan results, you can make changes and proceed toward migration within the same tool. That tighter loop simplifies project management and removes the need to correlate SMAT logs with a separate migration tool.

Who Should Run a Final SMAT Scan?

If your organization has any of the following, a final SMAT baseline makes sense:

  • Previous SMAT reports used to guide remediation decisions.
  • Custom ScanDef.json modifications that exclude certain scans.
  • Sites listed in SiteSkipList.csv for operational reasons.
  • Automated SMAT scripts tied to scheduled tasks.

Without that history, starting fresh with SPMT is less disruptive than creating a temporary SMAT dependency only to abandon it weeks later. The deadline is real, but overextending an old tool isn’t necessary for every farm.

The Configuration Quicksand: Why Your Old SMAT Settings Matter

SMAT’s flexibility is also its greatest liability. ScanDef.json may have disabled scans years ago for reasons nobody remembers. SiteSkipList.csv might still exclude sites that were supposed to be decommissioned but never disappeared. A clean-looking SMAT report might actually represent only a curated subset of your farm.

Before retiring SMAT, perform “configuration archaeology.” Open both files, document every deviation from defaults, and question each exception. A scan disabled in 2018 because it threw too many warnings might be the one that catches a critical migration blocker today. Sites that were skipped for a temporary project might still house live content.

Capturing the final SMAT run along with its configuration context turns a disappearing tool into a defensible record. Without that, you risk inheriting old blind spots into your new SPMT-driven assessments.

Step-by-Step: Making the Switch

For organizations that decide to run a final SMAT scan, follow this timeline. Waiting until the last week of September invites disaster—a failed scan or missing log could leave you with no recent baseline.

  1. Inventory your SMAT setup. Locate the executable package, scripts, ScanDef.json, SiteSkipList.csv, and any scheduled tasks.
  2. Document configuration decisions. Note every disabled scan and excluded site, along with the operational rationale if you can find it.
  3. Run the final scan. Execute smat.exe (or the version-specific executable like SMAT2013.exe) with the -q switch for quiet mode if automating. Allow the full one-to-two-day window.
  4. Preserve the entire Logs directory. Don’t just keep the summary; retain the full SMAT.log, SMAT_Errors.log, and any telemetry logs.
  5. Record metadata. Note the run date, farm identity, account used, and any differences from previous assessments.
  6. Begin SPMT scanning immediately. Start with a representative scope and compare its inventory and risk reports against the final SMAT output. Expect differences—SPMT won’t parrot SMAT’s format, but the major content and risk categories should align after accounting for any SMAT exclusions.

For those without SMAT history, the SPMT path is simpler:

  • Install or update to SPMT 4.0 or later.
  • Choose Add new scan and select a scanning method (single-site or bulk).
  • Enter source site locations and start the scan, or save it for later execution.
  • Once complete, open the scan from the list, review the dashboard, and download the detailed report.
  • Use that report to plan remediation and feed migration tasks.

The Reports Should Overlap, Not Match

When you run both tools during the transition, don’t expect identical output. SMAT’s config may have hid certain data; SPMT might surface new inventory and risks. Treat discrepancies as signals to investigate, not failures of one tool over the other.

A practical approach:
- Verify that all sites you expect in the SMAT baseline also appear in the SPMT assessment plan.
- Revisit any sites omitted by SiteSkipList.csv and decide if SPMT should scan them now.
- Re-enable any scans in ScanDef.json that might be valuable under current migration goals.
- Compare major inventory counts and risk categories; unexplained gaps may indicate scope differences.
- Save SPMT reports with clear labels so you can track progress over time.

This overlap also helps uncover abandoned exceptions. If a site was skipped because of an outdated decommissioning project, now is the time to either scan it or formally retire it.

If You’re New to Assessment

Organizations that have never used SMAT—or used it only once with default settings—face the easiest path. Skip SMAT entirely and start with SPMT. There’s no value in learning a deprecated tool that will be unsupported in two months. Your effort is better spent building familiarity with SPMT’s scan workflows, understanding its reports, and integrating them into your migration project.

Administrators managing SharePoint 2010, 2013, or 2016 farms should also remember that a scanner is not a substitute for migration planning. It identifies inventory and potential risks, but it won’t decide which content to move or how to handle obsolete sites. Those remain human-driven governance tasks.

Beyond October: Migrating with Confidence

October 1, 2026, is the end of SMAT support, not an order to delete historical evidence. Archive final logs and configuration files according to your data retention policies—they may be useful for explaining past migration decisions or for regulatory audits. But stop depending on them operationally. All new assessment scripts, automation, and team training should center on SPMT.

The broader lesson here is about managing Microsoft tool lifecycles proactively. SharePoint Online Alerts are also retiring this year, and other support deadlines are clustering. Now is the time to inventory every dependency that runs inside your SharePoint environment and ensure each has a supported path forward.

For farm admins, the next two months are a window, not a burden. A single deliberate SMAT run plus an orderly SPMT adoption is entirely achievable. The risk lies in putting it off until the calendar forces a rushed, undocumented transition. Use the time wisely.