Migrating to Microsoft Project 2010 & SharePoint 2010: Building a Virtual Migration Environment (VME)

Step-by-Step Guide: Creating a Virtual Migration Environment (VME) for Project 2010 and SharePoint 2010Migrating Microsoft Project Server 2010 and SharePoint Server 2010 — or moving existing Project and SharePoint workloads into a test or pilot instance — can be complex. Creating a Virtual Migration Environment (VME) lets you validate migration steps, test customizations, measure performance impacts, and reduce real-world risk. This guide walks you through designing, building, configuring, and using a VME tailored for Project 2010 and SharePoint 2010 migrations.

Why use a VME for Project 2010 and SharePoint 2010 migrations?

A VME provides a controlled, repeatable environment that mirrors important aspects of your production systems without affecting live users. Key benefits:

Validate migration procedures and rollback plans.
Test custom code, solutions, and third-party add-ins.
Rehearse upgrade paths and service pack/application of hotfixes.
Benchmark performance and capacity planning.
Train administrators and support staff.

Planning the VME

1) Define objectives and scope

Decide what you must validate in the VME. Typical objectives:

Full content and configuration migration of SharePoint 2010 farms.
Migrating Project Server 2007 (or earlier Project Server 2010 instances) to Project Server 2010.
Testing custom Web Parts, event receivers, workflows, and InfoPath forms.
Verifying service applications (Search, Managed Metadata, Excel Services).
Integration with authentication systems (Active Directory/claims).

Limit scope to what you need to test — a full-scale replica may be unnecessary and expensive. For initial runs consider a scaled-down topology (single-server or few-server) that still represents configuration and service boundaries.

2) Inventory production environment

Gather detailed information from production:

Farm topology (web front ends, application servers, database servers).
Windows Server versions and patch levels.
SQL Server version and configuration (collation, file layout, max memory).
SharePoint and Project Server service packs, cumulative updates, custom patches.
Web applications, zones, authentication types, managed paths.
Customizations: features, solutions (.wsp), assemblies, Web Parts, timer jobs.
Service applications and their settings (Search, Managed Metadata, User Profile, Excel Services, Secure Store).
Project Server specifics: PWA settings, enterprise custom fields, timesheet settings, reporting databases, PSI customizations.
Size metrics (database sizes, number of site collections, list sizes, number of users) to plan storage and performance testing.

3) Choose VME topology

Options:

Single-server VMs (all roles on one VM): quick and easy; good for functional tests and dev.
Multi-server VMs (separate SQL VM, SharePoint app VM, WFE VM): better for performance and service isolation.
Hybrid: single SQL VM + combined app/WFE VM.

For Project Server, separate SQL Server is recommended to reproduce database I/O behavior.

4) Hardware and licensing considerations

Allocate CPU, RAM, and disk to match scaled workload. Example minimal starting points:
- SQL VM: 4–8 vCPU, 16–32 GB RAM, FAST disks/SSD for DB files.
- App/WFE VM: 4 vCPU, 8–16 GB RAM.
- Single-server test VM: 8–12 vCPU, 24–32 GB RAM (depending on scale).
Use snapshots/checkpoints to capture baseline states and roll back failed runs.
Ensure you comply with Microsoft licensing for Windows Server, SQL Server, and SharePoint/Project Server in test environments.

Building the VME

5) Prepare the virtual infrastructure

Create virtual networks and VLANs to mimic production segmentation if needed.
Configure DNS entries for SharePoint web applications and service accounts.
Prepare domain controller VM (if isolated lab domain required) or ensure test domain is ready.
Set up time synchronization (Domain Controller authoritative).

6) Provision base OS and SQL Server

Install Windows Server versions matching production or the target versions you plan to use.
Harden and patch OS to the same update level as production when relevant to the test.
Install SQL Server on the SQL VM using the same edition and patch level. Configure:
- Max server memory (leave memory for OS and other services).
- Max degree of parallelism (consider setting to 1 for older CPUs).
- TempDB sizing (multiple data files on separate disks recommended).
- File placement for data, logs, and TempDB on appropriate virtual disks.

7) Install SharePoint 2010 and Project Server 2010 pre-reqs

Install required Windows Server features and roles (IIS, .NET Framework versions, Windows Identity Foundation if needed).
Apply any prerequisite installer or manual prerequisites for SharePoint 2010.
Install SharePoint 2010 binaries and apply the same service pack / cumulative update level as production.
Run SharePoint Products Configuration Wizard when ready.
Install Project Server 2010 components and apply patches to match production.

Restoring and configuring data

8) Bring databases into the VME

Decide whether to use full copies of production databases or trimmed subsets.

For functional testing and custom code verification use full copies.
For performance/load testing consider using full-size databases or a scaled but representative dataset.

Steps:

Back up production SharePoint and Project Server databases (Config DB, Content DBs, Service App DBs, Project Server Draft/Published/Reporting DBs).
Copy backup files to the SQL VM.
Restore databases on the VME SQL instance.
Use SQL logins and SQL Server SIDs mapping where necessary (sp_change_users_login or ALTER LOGIN … WITH SID = …).
Update any database connection strings, and ensure SQL aliasing if production DB server names are expected by SharePoint.

9) Repoint SharePoint farm configuration (carefully)

If restoring the farm config DB, you can attach to the restored config DB, but exercise caution — doing so effectively moves the farm identity and requires appropriate server names and account permissions.
Alternative safer approach: create a new farm and attach content DBs to web applications using Mount-SPContentDatabase. This keeps farm-level IDs separate and reduces risk of accidental conflicts.
For Project Server, restore the Project Server databases (Draft, Published, Reporting) and re-provision Project Server using PSConfig or PowerShell. Use Test-SPContentDatabase and Mount-SPContentDatabase to check for missing elements.

10) Update service application endpoints and managed accounts

Recreate or configure service applications as in production (or reuse restored service app DBs if appropriate).
Register managed accounts in Central Administration for service accounts used by timer service, app pools, and services.
Reconfigure Secure Store target applications if credentials were in production (reset/recreate keys if necessary).
Reindex Search if necessary and verify User Profile import connections point to a lab AD.

Handling customizations and integrations

11) Deploy solutions and custom code

Deploy custom WSPs, farm solutions, and assemblies to the VME.
Register any custom timer jobs and event receivers.
Validate assembly versions and GAC contents match production.

12) Verify InfoPath forms, workflows, and business data connections

Ensure InfoPath forms and forms services are deployed and working.
Repoint workflow endpoints and any external BCS/BDC connections to test endpoints.
Test Secure Store and service credentials used by workflows, Excel Services, or Project Server add-ins.

Project Server–specific steps

13) Re-provision Project Web App (PWA)

If you restored Project Server databases, re-provision PWA using the Project Server administration and PowerShell commands:
- Configure Project Service Application.
- Attach Project databases to the PWA instance.
- Recreate PWA site collection or attach existing content DB.
Validate queue jobs and timer service behavior (publish, calculation jobs).

14) Validate enterprise custom fields, views, and timesheet settings

Check that enterprise custom fields and lookup tables migrated correctly.
Validate timesheet periods, booking types, and resource availability settings.
Run a few project publish operations and ensure the reporting database updates as expected.

Testing and validation

15) Functional validation

Test common user scenarios: creating projects, assigning resources, publishing, timesheets, saving files to document libraries, site provisioning, and search queries.
Test administrative tasks: backup/restore from the VME, running PSConfig, applying a Cumulative Update and verifying rollbacks via snapshots.

16) Performance and load testing

Use tools like Visual Studio Load Test, JMeter, or third-party SharePoint load testing tools to simulate concurrent users.
Measure key metrics: SQL CPU and I/O, page response times, timer job durations, Project calculation and queue processing throughput.
Compare performance to production baselines to identify bottlenecks.

17) Security and authentication testing

Verify Windows and/or claims-based authentication scenarios.
Test Access Control Lists, permission levels, and user profile permissions.
Validate Single Sign-On or Secure Store Service integration if used.

Upgrades, patches, and rollback strategies

18) Test patching and upgrade sequences

Apply service packs or cumulative updates to the VME before production. Use snapshots to return to pre-patch states if needed.
Test custom code compatibility with the patches.
If you’re migrating from an older Project Server/SharePoint version, rehearse the upgrade path, and take note of required interim steps.

19) Create rollback and recovery plans

Use VM snapshots and SQL backups to build rollback plans.
Document exact steps to restore databases and configurations from the VME backups.
Validate backup/restore and farm recovery processes.

Cleanup and documentation

20) Capture findings and produce runbooks

Document issues found, configuration differences, performance numbers, and fix steps.
Produce runbooks for the production migration with step-by-step commands, required accounts, and contingency steps.
Include scripts used for mounting databases, reassigning SIDs, and reconfiguring services.

21) Sanitize sensitive data

If production data is used in the VME, mask or sanitize personally identifiable information (PII) according to your organization’s policies.
Reset service account passwords or Secure Store targets that contain production secrets.

Example minimal VME topology (recommended start)

Domain Controller VM (Windows Server)
SQL Server VM (SQL Server 2008 R2/2012 depending on prod)
SharePoint App/WFE VM (SharePoint 2010 + Project Server 2010)
Optional: Separate WFE VM for realistic load testing

Use snapshots at these milestones:

After OS and SQL installs
After SharePoint & Project Server installs but before data restore
After data restore and configuration
Before applying patches/updates

Troubleshooting common issues

Missing assemblies or feature IDs when mounting content DBs: use Test-SPContentDatabase and deploy missing WSPs or features.
Timer service jobs not running: check Windows Timer Service account, ensure managed account password is correct, and review ULS logs.
Search not returning results: confirm crawl component and index location, run full crawl, and check search topology.
SQL permission errors: ensure farm account and service accounts have proper SQL roles and SIDs map correctly.

Final notes

A VME helps you de-risk migrations by letting you validate each step in a safe environment. Keep the VME as close to production in configuration, patches, and customizations as practical, while balancing costs. Use it to verify migrations, rehearse upgrades, test patches, and train personnel so your production migration runs smoothly.

If you want, I can create:

A checklist runbook with PowerShell commands for each major step.
A sample topology diagram and resource sizing table for a small, medium, and large VME.