Overview
Systems represent the software platforms involved in your project. For migrations, you'll have both a source/legacy system and a target/new system. For enhancements or new implementations, you'll have just the target/new system you're building in.
What Are Systems?
System Information
For each system, Glossa stores:
Company - The vendor or creator of the platform (e.g., "Salesforce", "Microsoft", "Oracle")
Product Name - The specific product (e.g., "Sales Cloud", "Dynamics 365", "NetSuite")
Example entries:
Company: Salesforce | Product: Sales Cloud
Company: Microsoft | Product: Dynamics 365 CRM
Company: Oracle | Product: NetSuite
Company: Custom | Product: Legacy Donor Management System
Source/Legacy System
The system you're migrating from or replacing:
Only needed for migration projects
Represents the old platform being retired
Helps document what's being replaced
Examples:
Legacy custom-built CRM
Older version of a platform
Competitor platform being replaced
On-premise system moving to cloud
Target/New System
The system you're migrating to or building in:
Required for all projects (migrations and enhancements)
Represents the platform where work will be delivered
Where requirements will be implemented
Examples:
Salesforce (for CRM implementations)
NetSuite (for ERP projects)
Custom web application
Upgraded version of existing platform
Adding Systems
During Project Creation
Systems are added as part of the project creation flow:
For Migrations:
Enter Source/Legacy System:
Company name
Product name
Enter Target/New System:
Company name
Product name
For Enhancements:
Enter only Target/New System:
Company name
Product name
Modifying Systems to Existing Projects
You can modify systems after project creation:
Go to your project
Click Settings or Edit Project
Update system information:
Add source system if missing
Add target system if missing
Save changes
System Entry Format
Free Text Entry
System information is free text (not a pre-populated dropdown):
Benefits:
Works for any platform, including custom systems
No limitations on platform names
Flexibility for unique situations
Considerations:
No autocomplete or suggestions
Spelling must be consistent across projects
Users can enter systems differently ("Salesforce Sales Cloud" vs "SFDC Sales Cloud")
Recommended Format
For well-known platforms:
Use official product names
Company: "Salesforce" | Product: "Sales Cloud"
Company: "Microsoft" | Product: "Dynamics 365"
Company: "SAP" | Product: "S/4HANA"
For custom systems:
Company: "Custom" or "Internal" or "Legacy"
Product: Descriptive name of the system
Example: Company: "Legacy" | Product: "Donor Management System"
For version-specific:
Include version in product name if relevant
Product: "Salesforce Classic" vs "Salesforce Lightning"
Product: "NetSuite OneWorld 2024.1"
Using Systems
Documentation and Context
System information helps with:
Understanding project scope at a glance
Documenting what's being replaced/built
Categorizing projects by platform
Reporting on work by system type
Requirements Context
While systems are captured at the project level, they don't directly affect:
Requirement generation
Quality scores
Citations
Conflict detection
Systems are primarily for project metadata and organization.
Managing Systems
There is no dedicated Systems page or global systems view.
To see systems:
Open individual projects and view their system settings
Systems appear on the project dashboard/overview
Look at project settings to see full system details
Removing Systems
To remove a system from a project:
Open project settings
Clear the Company and Product fields for that system
Save
Note: You must have at least the Target/New System defined. You cannot remove all systems from a project.
Migration Projects vs. Enhancement Projects
Migration Projects
Setup:
Source System: The legacy platform being replaced
Target System: The new platform being implemented
Common scenarios:
Moving from one CRM to another
Upgrading from on-premise to cloud
Replacing custom-built system with commercial platform
Consolidating multiple systems into one
Example:
Source: Company "Legacy" | Product "Custom CRM v1"
Target: Company "Salesforce" | Product "Sales Cloud"
Enhancement Projects
Setup:
Target System only: The platform where you're adding features
Common scenarios:
Adding new functionality to existing Salesforce org
Building new module in existing ERP system
Enhancing portal with new capabilities
Example:
Target: Company "Salesforce" | Product "Nonprofit Cloud"
(No source system needed)
Best Practices
Consistent Naming
Establish standards:
Decide on official names for common platforms
"Salesforce" not "SFDC" or "SalesForce"
"Microsoft Dynamics 365" not "D365" or "Dynamics"
Document your standards:
Create a quick reference for team members
Include in onboarding documentation
Especially important for large teams or multiple project managers
Benefits:
Easier to search and filter projects
Cleaner reporting across projects
Reduces confusion about which platform is involved
Descriptive Custom Systems
For internal or custom systems, be descriptive:
Good:
Company: "Legacy" | Product: "Donor Management System"
Company: "Internal" | Product: "Employee Portal v2"
Company: "Custom" | Product: "Event Registration Platform"
Not as good:
Company: "Old" | Product: "System"
Company: "Custom" | Product: "Database"
Company: "Legacy" | Product: "CRM" (too generic)
Version Tracking
If version matters:
Include in product name:
Product: "Salesforce Classic" (if migrating to Lightning)
Product: "NetSuite OneWorld 2024.1"
Product: "Legacy Portal v1.5"
Or add to project name:
Project: "Salesforce Lightning Migration" (system is just "Salesforce" | "Sales Cloud")
Choose the approach that makes sense for your reporting needs.
Migration Documentation
For migrations:
Use source system to document legacy:
Capture the exact platform you're leaving
Include version if that context matters later
Helps with data mapping and migration planning
Use target system for implementation standards:
Be specific about the target platform variant
Note if it's a specific edition or configuration
Helps with technical requirements and constraints
Common Use Cases
Standard Platform Migrations
Scenario: Moving from one known platform to another
Example:
Source: Company "Microsoft" | Product "Dynamics CRM 2016"
Target: Company "Salesforce" | Product "Sales Cloud Enterprise"
Use: Clear documentation of old vs. new for stakeholders
Custom to Commercial
Scenario: Replacing homegrown system with commercial platform
Example:
Source: Company "Custom" | Product: "Legacy Donor Database"
Target: Company "Blackbaud" | Product: "Raiser's Edge NXT"
Use: Highlighting the modernization from custom to supported platform
Platform Enhancements
Scenario: Adding features to existing platform
Example:
Target: Company "Salesforce" | Product "Experience Cloud"
Use: Documenting which platform is being extended
Multi-System Consolidation
Scenario: Merging multiple legacy systems into one
Option 1 - Multiple projects:
Project 1: Source "Legacy ERP" → Target "NetSuite"
Project 2: Source "Legacy CRM" → Target "NetSuite"
Option 2 - One project:
Use project name: "Legacy Systems to NetSuite Consolidation"
Source: "Various Legacy Systems"
Target: "NetSuite"
Document specific systems in requirements or project notes
Troubleshooting
I can't save the project without a system
The Target/New System is required.
Solution:
Enter at least the company and product name for the target system
For migrations, also add source system information
I misspelled a system name
Systems are free text, so typos happen.
Solution:
Edit the project settings
Correct the spelling
Save
I can't find a list of all systems we use
There's no global systems view.
Workaround:
Review individual projects to see what systems are used
Should I include version numbers?
Include versions when:
Migrating from one version to another (Classic → Lightning)
Version affects requirements or implementation approach
Client is on a specific version that matters for scoping
Skip versions when:
Version doesn't impact requirements
You want cleaner project lists
The version is obvious from context (latest version assumed)