LabPC Modernisation Project
1. Purpose of this page
This Confluence page provides a central project overview for the LabPC Modernisation Project. It captures the project background, objectives, scope, phased delivery approach, workstreams, discovery activities, expected deliverables, key dependencies, and governance model.
The page should be used as the single reference point for stakeholders involved in the discovery, scoping, architecture, PoC, and final design phases of the LabPC modernisation initiative.
2. Executive summary
The LabPC environment supports scientific laboratories across multiple global sites. The current LabPC architecture was originally designed many years ago and now requires modernisation to address increasing challenges around operating system lifecycle, legacy authentication, storage scalability, data retention, backup, network standardisation, security, and cloud readiness.
The project is currently focused on understanding the current-state estate before moving into detailed architecture. This includes assessing existing server and storage capacity, network capability, security posture, cloud feasibility, Azure region suitability, data rate of change, and business continuity requirements.
The target direction is an Azure-first, hybrid cloud model that supports scientific lab requirements while respecting site-specific constraints such as data residency, instrument dependencies, network limitations, and regulatory requirements.
The project will not immediately roll out a new global solution. Instead, the objective is to produce a validated design, migration approach, cost model, and roadmap that can support future deployment.
3. Project background
The current LabPC model is used to support lab instruments, data acquisition, local processing, file transfer, and access to lab-generated data. In many locations, LabPCs are connected to scientific instruments via Ethernet, USB, or serial connections. Data is typically generated locally and then synchronized to a file server or storage location.
Several limitations have been identified in the current architecture:
Legacy LabPC architecture originally designed around older operational patterns.
Windows 10 lifecycle and future Windows 11 compatibility requirements.
Legacy LACS authentication system that is old, poorly documented, and not aligned with future Entra ID / modern IAM direction.
Site-level storage pressure, including local file servers, NAS, SAN, and local LabPC storage.
PeerSync dependency for data synchronisation from LabPCs to file servers.
Inconsistent backup, retention, and disaster recovery posture.
Lack of consistent documentation across sites.
- Software License management
Need for country-specific or region-specific data residency controls.
Need to assess whether Azure cloud storage can become primary, backup, archive, or hybrid storage.
Need to standardise network, security, and operational patterns across all lab sites.
4. Project objectives
The main objective of the LabPC Modernisation Project is to design a modern, scalable, secure, and supportable lab computing platform.
Key objectives include:
Define a modern LabPC target architecture.
Support Windows 11 LTSC or equivalent future-ready operating system strategy.
Identify options for backward compatibility with obsolete or instrument-dependent lab applications.
Replace or modernize the current LACS authentication model.
Improve storage scalability, backup, retention, and archiving.
Assess Azure cloud readiness for lab data storage and migration.
Define secure and standardized network specifications for lab environments.
Ensure the design aligns with cybersecurity and compliance requirements.
Minimize impact to lab application lifecycles and instrument operations.
Reduce configuration complexity across the global LabPC estate.
Build a clear migration roadmap and prioritization model for approximately 70 sites.
5. Scope
In scope
The following areas are included in the study and design phases:
Current LabPC estate discovery.
Existing server, NAS, SAN, and local storage capacity assessment.
Data growth and rate-of-change analysis across LabPC sites.
Network capability and connectivity assessment per site.
Security posture and access model assessment.
Cloud feasibility and Azure region suitability assessment.
Current backup, retention, DR, and BC review.
Authentication and access control requirements.
LACS replacement considerations.
Future LabPC OS and workstation requirements.
Storage modernization options, including Azure Files, Azure Blob, backup, archive, and hybrid models.
Network segmentation and secured VLAN requirements.
High-level cost and workload estimation.
MVP / PoC candidate identification.
Target architecture principles and future design roadmap.
Out of scope
The following items are not expected to be delivered as part of the current study phase:
Full global rollout of the final LabPC solution.
Large-scale site migration execution.
Full remediation of all local site issues.
Replacement of every lab application.
Final production deployment of Azure storage or identity services.
Operational transition until the final design and RUN model are agreed.
6. Phased project approach
The project follows a phased approach from discovery through final design.
| Phase | Timeline | Purpose | Key outputs |
|---|---|---|---|
| Discover | Feb – Mid June | Build a factual understanding of the current estate | Cloud readiness, current running cost, DR/BC view |
| Scoping | Mid June – Mid July | Structure needs, pain points, use cases, and project scope | Use cases, architecture proposal, updated figures, Book of Specification |
| Architecture | Mid July – August | Define solution options, target architecture, and cost estimates | Architecture design, high-level cost plan |
| MVP | August – September | Validate technical and functional solution assumptions | PoC results, test results, assessment criteria |
| Final Design | October – November | Finalize target architecture, rollout plan, RUN model, and cost plan | Validated architecture, standards list, rollout plan, RUN RACI, CAPEX/OPEX model |
7. Phase 1: Discover
Purpose
The Discover phase is focused on gathering reliable current-state information across all LabPC sites. The objective is to understand the existing technical landscape, identify gaps, and build a clear baseline before moving into formal scoping and architecture.
Main discovery activities
Discovery should focus on four primary assessment areas:
Existing server and storage capacity
Existing network capability
Existing security posture
Cloud readiness and Azure feasibility
Discovery inputs
The following inputs should be collected and reviewed:
Existing landscape documentation.
VMware reporting.
Firewall and load balancer trend reports.
Network utilization and capacity reports.
Storage capacity reports.
Backup and restore reports.
Logging and monitoring data.
Stakeholder interviews.
Site-level information from IT, LabPC Support, Hosting, Network, Security, and Finance teams.
Discovery stakeholders
Key stakeholder groups for the discovery phase include:
LabPC Support.
Network Chapter.
Security.
Hosting.
FinOps.
Site IT contacts.
Lab service owners.
Business stakeholders.
Project manager and solution architects.
Discovery deliverables
Expected outputs from the Discover phase include:
Current-state LabPC estate baseline.
Storage capacity assessment by site and device.
Network capability assessment by site.
Security posture assessment.
Cloud readiness assessment.
Azure region feasibility view.
Current running cost baseline.
Initial DR/BC assessment.
Data rate-of-change view by site.
Site prioritization model.
Initial list of blockers, risks, and gaps.
8. Discovery workstreams
8.1 Storage capacity and data change rate
This workstream captures the current storage landscape across all LabPC sites.
Key tasks:
Identify all LabPC-related storage locations per site.
Capture server, NAS, SAN, and local storage devices.
Document provisioned capacity, consumed capacity, and remaining capacity.
Calculate storage utilization percentage.
Identify data types stored, including raw data, test data, processed data, archive data, and backup data.
Capture data rate of change by site.
Identify sites with high storage pressure or rapid data growth.
Identify where local LabPC C: drive storage is used for critical data.
Review current PeerSync usage and synchronization behavior.
Identify whether cloud storage could be primary, backup, archive, or hybrid for each site.
Suggested output: Storage Capacity and Data Change Rate Spreadsheet
Minimum spreadsheet columns:
Site Name
Country / Region
Storage Device Name
Storage Device Type: SAN, NAS, File Server, Local, Other
Provisioned Capacity
Consumed Capacity
Remaining Capacity
Utilization %
Data Type
Data Rate of Change
Growth Trend
Business Criticality
Backup Coverage
Data Residency Constraint
Notes / Assumptions
Data Owner / Contact
8.2 Network capability
This workstream determines whether each site has the required network capacity, stability, segmentation, and connectivity model to support future Azure-based or hybrid storage patterns.
Key tasks:
Capture current WAN bandwidth per site.
Capture latency and packet-loss trends where available.
Review firewall and load balancer trend reports.
Identify current connectivity between LabPCs, file servers, office PCs, and cloud services.
Confirm whether the lab network is segmented from office and corporate networks.
Document existing VLANs, firewall rules, routing, and network constraints.
Identify whether site-to-site VPN, ExpressRoute, or existing private connectivity is available.
Assess whether each site can support Azure Files, Azure File Sync, backup replication, or archive workloads.
Identify sites with limited bandwidth or unstable connectivity.
Identify whether remote access is via VPN, TeamViewer, office PC, jump host, or another support model.
Define network performance benchmark criteria for future architecture.
Identify network blockers that must be resolved before migration.
Suggested owners:
Network Chapter
Cybersecurity / OT Network
Hosting
Site IT
Solution Architect
Expected output:
Network capability matrix by site.
Site readiness score for Azure connectivity.
List of network blockers and remediation actions.
Recommended connectivity pattern per site.
8.3 Security posture
This workstream assesses the current security baseline and future security requirements for LabPC modernization.
Key tasks:
Document current authentication model, including LACS dependency.
Identify where LACS is used and what business functions it supports.
Capture current user access model and AD group structure.
Confirm whether users access only their own data or shared site/team data.
Identify any shared accounts, service accounts, or local administrator usage.
Review current remote access model for support and users.
Identify cybersecurity requirements for lab, office, industrial, and QC environments.
Assess whether current logging and audit trails are sufficient.
Review backup security, including ransomware protection and immutability requirements.
Identify security requirements for Azure storage, including encryption, private endpoints, RBAC, and conditional access.
Assess whether data classification and data residency requirements are documented.
Define security gaps that must be addressed during architecture.
Suggested owners:
Security
IAM
Cybersecurity
OT Network
Workplace
LabPC Support
Solution Architect
Expected output:
Security posture assessment.
LACS dependency and replacement impact summary.
Identity and access gap analysis.
Remote access risk assessment.
Security requirements for target architecture.
List of security blockers and decisions required.
8.4 Cloud readiness and Azure feasibility
This workstream determines which sites are ready for Azure migration and which sites require remediation before migration.
Key tasks:
Identify the nearest feasible Azure region for each site.
Confirm country-specific data residency requirements.
Determine whether sensitive lab data can be stored in Azure for each country/site.
Assess whether Azure storage can be used as primary, backup, archive, or hybrid storage.
Review expected data egress and ingress patterns.
Assess cloud storage suitability based on data volume, data rate of change, and access frequency.
Identify candidate Azure services, including Azure Files, Azure Blob Storage, Azure Backup, Azure File Sync, Azure Monitor, and Azure Virtual Desktop where relevant.
Identify whether each site should follow cloud-first, hybrid, or constrained architecture pattern.
Capture cost drivers for each site, including storage tiering, backup, network, and egress.
Identify FinOps requirements for tracking cost by site, region, and workload.
Classify sites into migration priority categories: urgent, ready, blocked, or can wait.
Suggested owners:
Hosting
Cloud Architect
FinOps
Security
Network Chapter
LabPC Support
Site IT
Expected output:
Cloud readiness assessment.
Azure region feasibility matrix.
Site migration priority score.
Initial Azure cost considerations.
List of sites suitable for MVP / PoC.
List of cloud blockers and required decisions.
9. Site prioritization model
Sites should be grouped into migration categories based on objective criteria.
Candidate prioritization criteria
Storage capacity pressure.
Data rate of change.
Network capacity and stability.
Azure region feasibility.
Security and compliance constraints.
Business criticality.
Backup and DR risk.
Complexity of local applications and instruments.
Proposed site categories
| Category | Description | Action |
|---|---|---|
| Urgent | High storage pressure, high data growth, business-critical workloads, or high risk | Prioritize for early remediation or MVP |
| Ready / Quick Win | Good network, feasible Azure region, moderate complexity | Use for early migration wave |
| Blocked / Complex | Network, regulatory, app, instrument, or security blockers | Resolve blockers before migration |
| Can Wait | Low storage pressure, stable data, lower business risk | Plan for later wave |
10. Scoping phase
Purpose
The Scoping phase will use the discovery outputs to define clear business needs, pain points, use cases, and project boundaries.
Activities
Project preparation.
Needs collection.
Structuring of discovery findings.
Validation with SteerCo.
Prioritization of use cases.
Definition of architecture principles.
Book of Specification preparation.
Inputs
Pain points.
User feedback.
Stakeholder list.
Discovery outputs.
Current-state storage, network, security, and cloud readiness findings.
Deliverables
Use cases.
Architecture proposal.
Updated figures.
Book of Specification.
Macro planning.
Project governance model.
11. Architecture phase
Purpose
The Architecture phase will translate scoped requirements into target design options, with clear pros, cons, risks, and estimated costs.
Activities
Technical needs analysis.
Solution scenario definition.
Workshops with IT domains and business stakeholders.
HLD and LLD definition.
Cost estimation.
Architecture review and SteerCo validation.
Inputs
Use cases.
Architecture proposal.
Updated figures.
Project governance.
Discovery and scoping outputs.
Deliverables
Target architecture design.
Security model.
Storage architecture.
Network architecture.
Identity and access model.
High-level cost plan.
Architecture decision log.
12. MVP/PoC phase
Purpose
The PoC phase will validate selected technical and functional assumptions before the final design is completed.
Activities
Prepare test plan.
Set up required infrastructure.
Perform technical and functional testing.
Validate performance with key users.
Analyze results and feedback.
Validate PoC outcomes with SteerCo.
Inputs
Architecture design.
Test plan.
Assessment criteria.
Deliverables
PoC results.
Performance benchmarks.
Functional validation.
Design adjustments.
Go / No-Go recommendation.
13. Final design phase
Purpose
The Final Design phase will finalize the solution design and produce the materials required for future rollout.
Activities
Technical finalization.
Rollout planning.
RUN RACI definition and adjustment.
Final cost review.
CAPEX versus OPEX assessment.
SteerCo validation.
Inputs
Refined architecture.
PoC results.
Refined criteria.
Cost assumptions.
Stakeholder feedback.
Deliverables
Validated architecture.
Standards list.
Rollout plan.
RUN RACI matrix.
Cost plan.
Final design pack.
14. Main workstreams
The project should be structured around the following workstreams:
| Workstream | Purpose |
|---|---|
| Workplace / LabPC | Define future LabPC build, OS, hardware standards, and compatibility model |
| Storage | Define cloud-based extensible storage, backup, retention, and archive strategy |
| Network | Define secure VLAN, connectivity, performance benchmarks, and site network readiness |
| IAM / Authentication | Replace LACS and define Entra-compatible access management |
| Hosting / Cloud | Define Azure landing zone, cloud services, regions, and hybrid hosting model |
| Security | Provide transversal security control, compliance requirements, and risk review |
| OT Network | Validate lab and instrument network constraints |
| FinOps | Build cost visibility, current running cost, Azure cost model, and optimization approach |
| Business / Lab Users | Validate use cases, business impact, and operational requirements |
15. Key project decisions required
The following decisions should be tracked during discovery and scoping:
What is the future role of Azure storage: primary, backup, archive, or hybrid?
What is the replacement strategy for LACS?
Which Azure regions are acceptable per country/site?
What data must remain in-country?
What is the minimum acceptable backup and DR model?
What are the RPO/RTO expectations for R&I, Industrial, and QC labs?
What remote access model is acceptable for support and users?
Which sites should be selected for MVP or PoC?
What should be standardized globally versus handled as a local exception?
What is the future operating model and RUN ownership?
16. Key risks
| Risk | Impact | Mitigation |
|---|---|---|
| Incomplete discovery data | Architecture decisions may be based on assumptions | Use structured spreadsheet templates and assign data owners |
| Regional compliance constraints | Cloud storage options may be limited | Validate Azure region feasibility early |
| Network limitations | Azure storage or sync may not perform as expected | Run network capability assessment before architecture |
| LACS dependency | Identity modernization may become a blocker | Document current LACS functions and replacement requirements |
| Storage growth underestimated | Azure sizing and cost model may be inaccurate | Capture data rate of change and growth trends |
| Security review findings | Target design may require rework | Involve security from discovery phase |
| Resource constraints | Schedule delays | Assign clear owners per workstream |
| Business disruption | Lab operations could be impacted | Use MVP / PoC before wider rollout |
17. Success criteria
The project will be considered successful if it delivers:
A clear current-state baseline across all LabPC sites.
Validated storage, network, security, and cloud readiness data.
Site prioritization model for all labs.
Clear distinction between urgent, ready, blocked, and lower-priority sites.
Target architecture options with pros, cons, and cost implications.
A validated PoC or MVP approach.
Final architecture design and rollout roadmap.
Defined RUN model and RACI.
Financial view covering CAPEX, OPEX, and Azure consumption.
Security, compliance, and data residency considerations embedded in the design.
18. Immediate next steps
Complete discovery data collection for all known sites.
Assign owners for storage, network, security, cloud feasibility, and FinOps data collection.
Validate current server, NAS, SAN, and local storage capacity.
Capture data rate of change by site.
Complete network capability assessment.
Complete security posture and LACS dependency assessment.
Complete Azure region feasibility assessment.
Build site readiness and priority scoring model.
Identify candidate MVP / PoC sites.
Prepare discovery summary for review before entering the scoping and architecture phases.