Organizations using Siemens Teamcenter Rich Client (RAC) are increasingly evaluating Active Workspace (AWC) as a modern, web-based way to access PLM data and processes.
But moving from RAC to AWC is not simply a matter of replacing one user interface with another.
A successful RAC-to-AWC initiative requires an assessment of existing customizations, configurations, workflows, integrations, reports, user requirements, and business processes. It also provides an opportunity to determine which capabilities should be retained, reconfigured, redesigned, replaced, or retired.
RAC-to-AWC modernization is primarily a client and user-experience transformation. It is not inherently a Teamcenter data migration or a Teamcenter version upgrade. Depending on the project scope, however, it may be carried out alongside a Teamcenter upgrade, customization program, integration changes, or data-related activities.
PLM Nordic helps organizations assess and improve their Teamcenter environments through independent consulting, Teamcenter customization, Active Workspace development, data utilities, reporting, testing, and project support.
Why Strategy Comes Before Modernization
A RAC-to-AWC initiative should begin with business and user requirements rather than development work.
Many organizations have accumulated years of custom code, workflows, reports, integrations, configurations, and user-specific workarounds. Rebuilding everything in AWC without assessing its value can simply reproduce unnecessary complexity in a new interface.
Before deciding what should be transitioned, organizations should define the outcomes they expect from the modernization initiative.
These may include:
- Faster access to engineering information
- Reduced manual data entry
- Less duplicate work and rework
- Better visibility into product structures
- More consistent reporting
- Improved usability for occasional users
- Reduced dependency on client-side applications where appropriate
- Stronger process and data traceability
These objectives provide a basis for deciding which RAC capabilities should be:
- Migrated or reimplemented
- Reconfigured
- Redesigned
- Replaced
- Retired
- Investigated further
The objective is not to reproduce every RAC function in AWC. It is to deliver the capabilities users and the business actually need.
Step 1: Audit the Existing Teamcenter Environment
The first step is to establish what exists today.
A comprehensive assessment should cover:
- RAC customizations
- ITK and C/C++ utilities
- BMIDE configurations and extensions
- Existing Active Workspace extensions
- Workflows and business rules
- Reports and dashboards
- CAD integrations
- ERP, MES, and quality-system integrations
- Data utilities and batch processes
- User roles and department-specific requirements
- Custom forms, commands, panels, and menus
The assessment should also identify functions that are no longer used, have limited adoption, or exist because of historical workarounds.
These functions may not need to be recreated in AWC.
Create a RAC customization inventory
A useful inventory should classify each existing capability according to its future treatment:
| Existing capability | Possible treatment |
|---|---|
| Still required and supported by standard AWC | Reconfigure |
| Required but not available out of the box | Customize / reimplement |
| Business process has changed | Redesign |
| Function duplicated elsewhere | Replace |
| No longer required | Retire |
| Requirement unclear | Investigate |
This creates a more realistic scope than a general request to “move from RAC to AWC.”
Step 2: Map Business Requirements to Active Workspace
Active Workspace provides a different interaction model from the traditional rich client.
Users work through browser-based pages, commands, panels, object information, role-based experiences, and configurable interfaces.
Existing RAC functionality should therefore be assessed against actual business requirements rather than copied line by line.
For each process, ask:
- Who uses this function?
- How frequently is it used?
- What business problem does it solve?
- Can the requirement be addressed through standard AWC functionality?
- Can it be addressed through AWC configuration or declarative UI?
- Does it require a custom client-side extension?
- Is a server-side service or ITK utility required?
- Does the process require integration with another system?
- Can the process be simplified?
- Is the function still necessary?
This approach helps avoid creating a new AWC environment that contains the same unnecessary complexity as the old RAC environment.
Step 3: Configure, Redesign and Customize for the Target Experience
Where custom functionality is required, it should be designed for the AWC experience rather than treated as a direct lift-and-shift exercise.
Active Workspace supports declarative UI configuration and command development, allowing organizations to tailor pages, panels, commands, actions, conditions, and related behaviors. More extensive requirements can involve client-side and server-side customization.
Depending on the requirement, implementation may involve:
Active Workspace / client-side
- Workspaces
- Commands and command handlers
- Declarative UI configuration
- Custom panels and views
- Data providers
- Themes and styles
- Applicable client-side extensions
Teamcenter / server-side
- SOA services
- ITK utilities
- C/C++ development
- BMIDE configuration and extensions
- Business rules and server-side logic
Supporting solutions
- Customer-specific reports
- Data validation utilities
- Data conversion or export utilities
- Integration changes
- Automated processing and reporting
Siemens’ current Active Workspace training and documentation explicitly cover client-side customization, declarative customization, server-side ITK/SOA development, BMIDE, and custom services.
The key principle is simple:
Do not rebuild the RAC interface. Recreate the business capability in a way that fits the AWC experience.
A good customization should be understandable, maintainable, and aligned with the user’s workflow rather than becoming another disconnected tool.
PLM Nordic’s Active Workspace work includes defining AWC UI elements and panels, configuring commands and associated actions, developing customer-specific reports, and supporting testing and delivery.
Step 4: Validate Data Access, Relationships and Integrations
A RAC-to-AWC modernization project does not inherently require moving Teamcenter data to a new repository.
Instead, the project should validate that users can access the required information and that important Teamcenter relationships, business rules, permissions, and integrations continue to work as expected through Active Workspace.
Validation should include:
- Item and revision data
- Dataset relationships
- Attachments
- Release status
- Properties and attributes
- Where-used information
- Where-referenced information
- BOM structures
- Change information
- Access permissions
- CAD relationships
- ERP and other system integrations
Where the modernization is being performed alongside a Teamcenter version upgrade or a separate data migration/conversion project, those activities should be treated as related but distinct workstreams.
Automated utilities can be useful when large numbers of items or datasets need to be processed. They can also provide logging and reporting when expected files, attributes, or relationships are missing.
Example: Teamcenter data utility
PLM Nordic developed a STEP and PDF export utility for a sports car manufacturer in the United States.
The utility processed a list of item IDs, exported available STEP and PDF files, logged missing files, and maintained relevant attributes, release status, attachments, where-used information, where-referenced information, and other relationships. Existing items were retained in the database for future reference.
The project helped reduce manual work, improve consistency, and reduce the risk of errors during file conversion and export.
This type of utility is complementary to RAC-to-AWC modernization rather than being a RAC-to-AWC migration itself.
Step 5: Test with Real User Scenarios
Technical validation should be combined with realistic user acceptance testing.
A useful test plan can include:
- Standard business processes
- Custom commands and panels
- BOM navigation
- Reporting requirements
- Data access and security
- Large and complex product structures
- Error handling
- Missing-data scenarios
- Supported browser environments
- Performance testing
- CAD and ERP integration testing
- Regression testing after changes
User acceptance testing should involve representatives from the departments that use Teamcenter regularly.
Their feedback can reveal issues that are not always visible during technical testing, particularly around:
- Navigation
- Terminology
- Report content
- Number of steps required to complete a task
- Visibility of information
- Role-specific workflows
- Custom functionality
Example: Active Workspace reporting customization
PLM Nordic’s AWC customization work for a rubber-processing machinery company included test-case definition and execution as part of the project scope.
The requirement was to generate HTML reports for selected nodes in a BOM structure rather than producing a report for the entire structure. The solution enabled users to open the reports in Chrome or another standard browser.
The project used Teamcenter AWC 6.3, Teamcenter 14.3, JavaScript, SOA, and C++.
This example demonstrates the type of focused customization and testing that can support an AWC implementation. It should not be interpreted as a complete RAC-to-AWC migration project.
Step 6: Train Users and Roll Out in Phases
Even a technically successful modernization can struggle if users do not understand the new experience.
Training should be role-based and focused on real tasks.
Different user groups may need guidance on:
- Finding items and revisions
- Navigating BOM structures
- Running reports
- Reviewing documents
- Managing changes
- Using custom commands
- Understanding new terminology
- Handling errors or missing data
A phased rollout can reduce implementation risk.
It may include:
- A pilot group
- Department-by-department deployment
- Parallel access for critical users where appropriate
- A defined hypercare period
- Issue tracking and prioritization
- A rollback or contingency plan
- Post-launch adoption reviews
The objective is not simply to complete the technical deployment.
The objective is to ensure that users can perform their required work effectively in the new environment and that the organization can measure whether the modernization achieved its intended outcomes.
Where PLM Nordic Can Add Value
Organizations may engage a large systems integrator when a Teamcenter initiative is part of a wider ERP, cloud, or enterprise transformation.
For focused Teamcenter work, organizations may also engage an independent specialist with relevant technical experience.
PLM Nordic can support organizations with:
- Teamcenter RAC and AWC consulting
- RAC-to-AWC modernization assessment
- Active Workspace configuration and customization
- Declarative UI configuration
- Teamcenter reporting
- ITK and C/C++ utilities
- SOA-based solutions
- CAD data export and processing
- Data validation and conversion
- BOM-related functionality
- Test-case definition and execution
- Project management
- Technical documentation
- Existing customization assessment
The appropriate delivery model depends on the scope, internal resources, integration landscape, existing Teamcenter architecture, and level of specialist support required.
For an RAC-to-AWC initiative, the first step should be understanding the current environment and identifying what actually needs to change.
How to Build the Business Case
The business case for an RAC-to-AWC modernization initiative should be based on the organization’s own data.
Potential areas to measure include:
- Time saved on repetitive operations
- Fewer manual errors
- Reduced data rework
- Faster access to product information
- Improved reporting
- Reduced support effort
- Better process consistency
- User adoption
- Productivity improvements in targeted workflows
A simple internal calculation can compare expected annual benefits with project cost:
ROI (%) = [(Annual Benefits − Project Cost) ÷ Project Cost] × 100
The inputs should come from the organization’s current-state assessment, pilot project, user interviews, and measured process improvements.
Generic industry averages are less useful than measurements from the actual Teamcenter environment.
RAC-to-AWC Modernization Is an Opportunity to Improve
Moving from RAC to AWC should not be treated as a software replacement exercise alone.
It provides an opportunity to examine how users access product information, how business processes are executed, which customizations remain valuable, and where unnecessary complexity can be removed.
A structured approach is:
- Audit the current Teamcenter environment
- Define measurable business outcomes
- Map requirements to AWC
- Configure standard capabilities where possible
- Redesign or customize only what is required
- Validate data access, relationships, security, and integrations
- Test with real user scenarios
- Train teams by role
- Roll out in manageable phases
- Measure adoption and business outcomes after launch
Most importantly, remember that these are related but different activities:
RAC → AWC = Client / UX Modernization
Teamcenter version change = Upgrade
Moving or transforming PLM data = Data Migration / Conversion
Adapting Teamcenter behavior or UI = Configuration / Customization
A project may contain several of these workstreams, but they should not be treated as the same activity.
How PLM Nordic Can Support Your RAC-to-AWC Initiative
PLM Nordic provides independent Teamcenter consulting and technical services covering Active Workspace customization, Teamcenter configuration, reporting, data utilities, testing, and project support.
Organizations considering an RAC-to-AWC modernization can begin with a focused assessment covering:
- Existing RAC customizations
- Current AWC capabilities
- Business and user requirements
- Teamcenter configuration
- Integrations
- Reports and utilities
- Customization dependencies
- Testing requirements
- Migration or upgrade dependencies
The result can be a practical roadmap showing what should be retained, reconfigured, redesigned, replaced, or retired.
Considering a move from Teamcenter RAC to Active Workspace? Contact PLM Nordic to discuss your current Teamcenter environment and modernization requirements.
