Some links on this page are affiliate links: if you buy through them we may earn a commission, at no extra cost to you.
Windows SharePoint Services 3.0 (WSS 3.0) was Microsoft’s on-premises collaboration platform released in 2006. It supplied team sites, document libraries, lists, permissions, and extensibility—and served as the foundation for Microsoft Office SharePoint Server 2007, a separate, more capable enterprise product. WSS 3.0 reached the end of extended support on October 10, 2017. Today, treat an existing farm as a source to preserve, recover, or migrate—not as a platform for a new production deployment.
“SharePoint 2007” can mean either WSS 3.0 or Office SharePoint Server 2007, so identifying the product and its customizations is an essential first step when maintaining an old installation.
What Windows SharePoint Services 3.0 was
WSS 3.0 was Microsoft’s server-side platform for browser-based team collaboration. Organizations used it to create SharePoint sites where people could manage documents, structured lists, calendars, announcements, tasks, discussions, and other shared information. It was more than a file server: sites combined content with metadata, permissions, version history, workflows, alerts, and integration with Microsoft Office.
Free tools Windows power users keep installed
One-click scans. No signup required.
Microsoft released WSS 3.0 on November 13, 2006. Its product-line successor was SharePoint Foundation 2010, which Microsoft described as the new version of Windows SharePoint Services and as underlying infrastructure for SharePoint Server (Microsoft’s SharePoint Foundation 2010 download page).
#1 Best Overall
The name can be confusing. “SharePoint 2007” is often used loosely for both WSS 3.0 and Microsoft Office SharePoint Server 2007 (MOSS 2007). They were related, but not interchangeable products.
WSS 3.0 and Office SharePoint Server 2007 compared
| Area | WSS 3.0 | Office SharePoint Server 2007 |
|---|---|---|
| Team sites and workspaces | Core platform capability | Included, built on WSS |
| Document libraries, lists, calendars, tasks | Core collaboration features | Included, with broader enterprise options |
| Permissions and site administration | Available | Available, with additional enterprise management capabilities |
| Web Parts and customization | Supported | Supported, with broader product capabilities |
| Publishing, enterprise content management, records management, business intelligence | More limited foundation capabilities | Expanded enterprise features, depending on edition and configuration |
| Licensing distinction | Foundational service, generally associated with Windows Server licensing rather than a separate enterprise SharePoint product license | Separately licensed enterprise product |
It is imprecise to call WSS 3.0 simply “the free version of SharePoint Server 2007.” WSS had its own product identity and provided the platform on which MOSS was built, but the products had materially different feature sets. WSS did not automatically include every publishing, search, records-management, or business-intelligence feature available in the enterprise product. Licensing and access costs depended on the deployment, Windows Server edition, and usage; the absence of the same separate enterprise product license did not make a deployment cost-free.
What users and developers could do with it
WSS sites brought together collaboration tools that otherwise might have been scattered across shared drives, email, and departmental applications:
Recommended Free Tools
- Sites and workspaces: Create team or project spaces from templates, with subsites and site collections for organizing different groups or purposes.
- Documents: Store files in libraries; use features such as version history, check-in and check-out, approval, metadata, content types, alerts, and Office integration.
- Structured information: Maintain lists for announcements, contacts, calendars, tasks, links, discussions, surveys, and custom records.
- Access control: Assign permissions at relevant scopes, with the option to inherit or break inheritance as a site was organized.
- Customization: Extend sites using Web Parts, Features, event receivers, workflows, site definitions, SharePoint Designer customizations, and server-side code.
The platform’s extensibility also explains why old farms can be difficult to move. A site that looks like a collection of pages and files may depend on custom assemblies, workflows, modified master pages, or third-party components. Microsoft’s historical WSS 3.0 developer resource collection covers development by feature and theme.
How a WSS 3.0 farm was organized
A deployment—often called a farm—was a set of SharePoint servers and supporting services managed as a unit. Exact designs varied in size and configuration, but these terms help make sense of an inherited system:
- Farm: The overall SharePoint deployment and its shared configuration.
- Web application: A SharePoint application hosted through IIS, providing an application boundary and URL access.
- Site collection: A collection of sites managed within a common administrative and content boundary.
- Site: An individual collaboration workspace, often containing pages, libraries, and lists.
- Content database: SQL-backed storage for site content. A farm also relied on configuration data and supporting settings.
- Central Administration: The web interface for managing farm settings.
WSS deployments generally depended on Windows Server, IIS, ASP.NET and the .NET Framework, and a database option such as SQL Server or Windows Internal Database, depending on deployment type. Many intranets also used Active Directory and Windows authentication. Larger farms could separate web front-end servers from database servers. These are architectural components, not a single universal installation recipe: supported combinations depended on the exact WSS build, service pack, and deployment.
Service packs and support status
Microsoft’s WSS 3.0 lifecycle page records the release and support dates:
| Milestone | Date |
|---|---|
| Original release | November 13, 2006 |
| Service Pack 1 | December 11, 2007 |
| Service Pack 2 | April 24, 2009 |
| Service Pack 3 | October 24, 2011 |
| Mainstream support ended | October 9, 2012 |
| Extended support ended | October 10, 2017 |
End of support is a product-specific date. It is not the same as the end of support for SharePoint Foundation 2010, whose extended support ended April 13, 2021 (Microsoft lifecycle page). Neither WSS 3.0 nor Foundation 2010 should be treated as a currently supported stepping stone.
An old download page or installer does not change that status. Historical media may not include the required service packs, patches, prerequisites, or rights for a particular use. Avoid third-party mirrors unless you can independently establish the files’ provenance and integrity. Do not deploy WSS 3.0 as a new production platform or expose it to the public internet.
What to do with an inherited WSS 3.0 farm
Before upgrading, changing servers, or exporting content, establish what exists and preserve a recoverable copy. A working server is not proof of a tested recovery plan, and a content database alone may not capture the complete farm or its user experience.
Inventory the environment
- Record the WSS build and service-pack level, Windows Server version, and SQL Server or Windows Internal Database version.
- Count farms, web applications, site collections, sites, and content databases; record database sizes and ownership.
- Document authentication, service accounts, URLs, alternate access mappings, certificates, DNS, IIS settings, and Central Administration access.
- List custom Web Parts, Features, solutions, event receivers, workflows, site definitions, modified master pages, SharePoint Designer customizations, and third-party products.
- Identify scheduled jobs, integrations, search configuration, audit or usage needs, and external dependencies.
- Find the business owner for each site collection. Mark content for migration, archive, rebuild, export, or deletion rather than assuming everything should move.
- Review permissions, inherited access, direct grants to individuals, nested directory groups, and unresolved users.
- Locate backups and confirm when a restoration was last tested.
Preserve before making changes
- Create a full infrastructure backup and, where practical, preserve the original server or virtual-machine image.
- Back up SharePoint content and configuration databases and document the database and SQL configuration.
- Capture farm configuration, IIS settings, URLs, DNS records, certificates, authentication settings, custom deployment packages, and scheduled jobs.
- Restore a copy on an isolated network and test that it behaves as expected before using it as a migration source.
- Keep the original untouched until the restored copy and migration outputs have been validated.
Do not run a historical upgrade procedure against the only copy of a farm. Exact commands and supported steps depend on the source build, service-pack level, topology, and destination. A command that is right for one legacy farm may be wrong for another.
Historical upgrade paths—and their limits today
Microsoft’s historical guidance for moving from WSS 3.0 or Office SharePoint Server 2007 to SharePoint 2010 Products describes three broad approaches: in-place upgrade, database-attach upgrade, and a hybrid approach (upgrade approaches; upgrade planning guidance). That is useful historical documentation, not a supported 2026 route to current SharePoint.
Best Value
| Approach | Potential advantage | Main risks and costs |
|---|---|---|
| In-place | May retain aspects of the existing topology and configuration with fewer parallel systems. | Can require a longer outage, offers a harder rollback, and carries forward existing faults and customization problems. Hardware or operating-system constraints may prevent it. |
| Database attach | Build a new farm and attach content databases, providing a cleaner infrastructure and room to test while keeping the old farm as a fallback. | Customizations must be redeployed or rebuilt; unsupported or damaged content can fail; URLs, authentication, and feature dependencies require planning. |
| Hybrid | Combines approaches to fit a complex farm or reduce disruption. | Requires careful sequencing and testing to avoid version, schema, or customization mismatches. |
A database attach is not a complete migration of a farm’s behavior. A successful database upgrade does not guarantee that pages will look the same, workflows will run, permissions will resolve, or links will remain valid. Microsoft’s documented material covers historical SharePoint 2010 upgrade paths; do not infer that a current SharePoint version accepts a WSS 3.0 database directly.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Choose a destination based on what the farm actually does
There is no single replacement that fits every legacy deployment. Decide whether the need is document management, an intranet, workflow automation, records management, or basic file sharing; then map the actual content and processes to an appropriate destination.
- SharePoint Online or Microsoft 365: Consider this when cloud hosting, Microsoft 365 integration, and reduced server maintenance fit the organization. It is a poor fit if air-gapped operation, incompatible server-side code, or regulatory constraints rule out the service. Microsoft’s SharePoint overview describes current Microsoft 365 and standalone SharePoint Online options.
- Modern SharePoint Server: Consider a supported on-premises product when hosting control or other requirements make cloud unsuitable and the organization can fund infrastructure and specialist administration. It is not a shortcut around assessing old customizations.
- Rebuild or use another platform: Consider this if WSS is mainly a small document repository or intranet and its customizations cost more to port than to replace. A simpler platform may be a better match, but first identify required metadata, access rules, workflows, and records obligations.
For a legacy farm, migration usually requires more than moving files. Decide deliberately how to handle version history, metadata, content types, permissions, workflows, alerts, audit context, discussion threads, custom forms, and links. Some elements may need redesign or export rather than a direct copy.
Migration problems to look for
- Custom code and pages: Web Parts, assemblies, site definitions, master pages, CSS, JavaScript, event receivers, and third-party add-ons may not work on a newer platform.
- Workflows: A workflow may depend on an old engine, custom assemblies, impersonation behavior, scheduled jobs, SMTP settings, or hard-coded URLs. Inventory its owner and business purpose before deciding whether to rebuild it.
- Permissions and identities: Direct grants, broken inheritance, deleted accounts, nested directory groups, and changed identity formats can create access gaps or over-sharing. Redesigning permissions can be safer than copying them exactly.
- URLs and references: Host-name changes, reorganized site collections, renamed libraries, rebuilt pages, and recreated search indexes can break links.
- Content quality: Expect to find duplicates, stale sites, excess versions, oversized files, obsolete metadata, invalid characters, long paths, broken lookups, unused content types, or sensitive material with weak access controls.
If immediate migration is not possible
A short-term preservation period may be reasonable when the farm contains important records, no backup has been proven, custom applications need investigation, or a funded migration is underway. It should have a defined end date and an approved exception—not become indefinite operation.
Reduce exposure by isolating the farm from the public internet, segmenting its network, restricting administrator access, disabling unnecessary services, using least-privilege accounts, maintaining offline tested backups, and monitoring access. Isolation can reduce exposure; it does not make an unsupported product secure. Set a retirement date and assign owners to data extraction, replacement, and validation.
Quick Recap
Common misconceptions
- “The server still works, so it is safe.” Functionality is not vendor support. WSS 3.0 has been out of extended support since October 10, 2017.
- “A content database backup is a complete backup.” Recovery may also depend on configuration, IIS, custom code, certificates, DNS, authentication, SQL settings, scheduled jobs, and integrations.
- “A successful upgrade preserves the site exactly.” Appearance, links, workflows, permissions, and custom behavior all require validation.
- “Foundation 2010 is a supported intermediate platform.” Its extended support ended in 2021.
- “Moving the documents is the same as migrating SharePoint.” A file move can omit versions, metadata, permissions, workflows, alerts, discussions, audit context, and retention requirements.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
