Migrate your OpenText Service Request Center (SRC) data
Enterprise ITSM platform acquired through Micro Focus, serving large organizations with deep knowledge-management and service-request workflows. Targets IT departments managing high ticket volumes across regulated industries.
In its favor
Why people choose OpenText Service Request Center (SRC)
The signal that keeps OpenText Service Request Center (SRC) on the shortlist. Sourced from G2, Capterra, and customer scoping calls.
Customers with deep existing OpenText or Micro Focus ITSM investments choose SRC because of established integrations with other OpenText modules, years of institutional knowledge embedded in workflows, and compliance posture suitable for regulated industries.
Enterprise IT departments managing high ticket volumes use SRC for its structured request-management process, including knowledge-base integration that routes agents toward resolutions before escalating incidents.
Organizations already standardized on OpenText Content Suite or Extended ECM select SRC because it integrates natively with document-management capabilities, allowing service requests to reference and attach content-suite assets.
Long-standing OpenText customers cite the vendor's longevity and scale as reassurance — a company with 22,900 employees and public listings on both NASDAQ and the Toronto Stock Exchange is seen as less likely to sunset a product.
The platform's support for complex SLA hierarchies and multi-tier service catalogs appeals to IT organizations managing internal and external-facing services with differentiated response commitments.
Pricing complexity and opacity drive organizations away — enterprise OpenText licenses routinely cost $200,000–$800,000 for mid-sized deployments, with annual maintenance adding significant ongoing spend that is difficult to benchmark against modern SaaS alternatives.
Legacy UI and configuration complexity frustrate users accustomed to modern helpdesk interfaces — the platform requires significant administrative overhead to configure and maintain, with steep learning curves for new administrators.
Organizations report difficulty achieving a modern, responsive self-service portal experience compared to newer ITSM platforms, particularly on mobile and across third-party integrations.
Vendor lock-in concerns grow as organizations accumulate years of custom fields, workflows, and integrations specific to SRC, making migration feel increasingly risky and expensive to undertake.
Limited API documentation and developer resources make it difficult for teams to build custom integrations or automate operations without specialized OpenText expertise.
Reasons to switch
Why people leave OpenText Service Request Center (SRC)
The recurring reasons buyers give for replacing OpenText Service Request Center (SRC). Presented as facts, not knocks.
Platform scorecard
Strengths, weaknesses, and where OpenText Service Request Center (SRC) fits
Grades across six dimensions, plus a SWOT-style view of where the platform shines and where it falls short.
SWOT — strengths, weaknesses, and use-case fit
Strengths
Weaknesses
Where it works
Where it struggles
Pricing tiers
OpenText Service Request Center (SRC) pricing overview
OpenText does not publish public pricing for SRC. On-premises licenses for comparable OpenText ITSM products run $200,000–$800,000 for mid-sized deployments (500–1,000 users), with annual maintenance adding 20–25% of the license cost. Cloud subscription pricing is negotiated directly with OpenText sales and is tiered by user count and module selection.
On-premises Enterprise License
Tier 1 of 3
Custom (~$200,000-$800,000 for 500-1,000 users, industry reference)
What's included
Need help selecting your Helpdesk?
Book a free 30 minute consultationPricing is informational. FlitStack AI does not bill on OpenText Service Request Center (SRC)'s schedule — see our quote-based pricing →
What gets migrated
OpenText Service Request Center (SRC) object support
Object-by-object support for OpenText Service Request Center (SRC) migrations. Per-pair details surface during scoping.
Service Requests
Fully supportedService Requests are the primary ticket object in SRC, representing user-initiated service requests. The platform maps requests through defined workflow stages and assigns them to support groups. We migrate Service Request records including all standard fields, current status, and assignment history.
Incidents
Fully supportedIncidents are distinct from Service Requests and track IT infrastructure or service disruptions. SRC maintains separate incident records with impact and urgency fields. We handle the separate incident object during migrations and map it to the destination's equivalent ticket type.
Knowledge Base Articles
Mapping requiredKB Articles in SRC store resolution content linked to tickets. Article-to-ticket associations are preserved during migration. However, article formatting, categories, and metadata structures vary significantly between SRC deployments, requiring field-level mapping during transfer.
Users
Fully supportedSRC maintains user records with login credentials, group memberships, and role assignments. We export user records including display name, email, department, and manager hierarchy. Passwords cannot be migrated and require re-authentication setup post-migration.
Customers
Mapping requiredExternal requesters are tracked as Customer records distinct from internal Users. Customer records include contact information and associated service requests. We migrate customer records but flag any custom customer properties for field-level mapping.
Attachments
Mapping requiredFiles attached to service requests and incidents are migrated with their parent records. Attachment migration requires careful handling of file size limits, storage path references, and any attachments stored in external content repositories linked via SRC.
Custom Fields
Mapping requiredBoth Service Requests and Incidents support extensive custom field configurations that vary by SRC deployment. We audit custom fields during the discovery phase, map them to destination equivalents, and flag any unsupported field types that require workarounds.
Workflows
Not in this platformSRC workflow definitions are tightly coupled to the platform's internal process engine and are not exportable in a portable format. We document workflow logic and reproduce it in the destination platform, but automated workflow migration is not supported.
SLA Definitions
Mapping requiredSLA configurations define response and resolution targets tied to priority levels and service categories. We export SLA definitions and map them to the destination's SLA model, noting any mismatches in calendar-based versus 24×7 coverage.
Service Catalogs
Not in this platformService catalog items and request offerings are defined within SRC's catalog module and are not migrated as structured records. We extract catalog item metadata and reconstruct catalog entries in the destination platform manually.
Teams and Groups
Fully supportedSupport groups and team assignments are standard SRC objects that define ticket routing and agent ownership. We export group membership, reporting hierarchies, and email routing aliases and recreate them in the destination platform.
| Object | Support | Notes |
|---|---|---|
| Service Requests | Fully supported | Service Requests are the primary ticket object in SRC, representing user-initiated service requests. The platform maps requests through defined workflow stages and assigns them to support groups. We migrate Service Request records including all standard fields, current status, and assignment history. |
| Incidents | Fully supported | Incidents are distinct from Service Requests and track IT infrastructure or service disruptions. SRC maintains separate incident records with impact and urgency fields. We handle the separate incident object during migrations and map it to the destination's equivalent ticket type. |
| Knowledge Base Articles | Mapping required | KB Articles in SRC store resolution content linked to tickets. Article-to-ticket associations are preserved during migration. However, article formatting, categories, and metadata structures vary significantly between SRC deployments, requiring field-level mapping during transfer. |
| Users | Fully supported | SRC maintains user records with login credentials, group memberships, and role assignments. We export user records including display name, email, department, and manager hierarchy. Passwords cannot be migrated and require re-authentication setup post-migration. |
| Customers | Mapping required | External requesters are tracked as Customer records distinct from internal Users. Customer records include contact information and associated service requests. We migrate customer records but flag any custom customer properties for field-level mapping. |
| Attachments | Mapping required | Files attached to service requests and incidents are migrated with their parent records. Attachment migration requires careful handling of file size limits, storage path references, and any attachments stored in external content repositories linked via SRC. |
| Custom Fields | Mapping required | Both Service Requests and Incidents support extensive custom field configurations that vary by SRC deployment. We audit custom fields during the discovery phase, map them to destination equivalents, and flag any unsupported field types that require workarounds. |
| Workflows | Not in this platform | SRC workflow definitions are tightly coupled to the platform's internal process engine and are not exportable in a portable format. We document workflow logic and reproduce it in the destination platform, but automated workflow migration is not supported. |
| SLA Definitions | Mapping required | SLA configurations define response and resolution targets tied to priority levels and service categories. We export SLA definitions and map them to the destination's SLA model, noting any mismatches in calendar-based versus 24×7 coverage. |
| Service Catalogs | Not in this platform | Service catalog items and request offerings are defined within SRC's catalog module and are not migrated as structured records. We extract catalog item metadata and reconstruct catalog entries in the destination platform manually. |
| Teams and Groups | Fully supported | Support groups and team assignments are standard SRC objects that define ticket routing and agent ownership. We export group membership, reporting hierarchies, and email routing aliases and recreate them in the destination platform. |
Gotchas
What to watch for in OpenText Service Request Center (SRC) migrations
Issues we've hit on past OpenText Service Request Center (SRC) migrations, tagged by severity. FlitStack AI handles every one — surfacing them up front because buyer engineering teams want to know.
SLA calendar and business-hours definitions vary by deployment
Custom field data types and validation rules are not portable
Attachment storage paths may reference external repositories
Knowledge base articles may contain HTML formatting incompatible with plain-text destinations
| Severity | Issue |
|---|---|
| Medium | SLA calendar and business-hours definitions vary by deployment |
| Medium | Custom field data types and validation rules are not portable |
| High | Attachment storage paths may reference external repositories |
| Low | Knowledge base articles may contain HTML formatting incompatible with plain-text destinations |
Leaving OpenText Service Request Center (SRC)?
Where OpenText Service Request Center (SRC) customers move next
7 destinations OpenText Service Request Center (SRC) can migrate to.
How a OpenText Service Request Center (SRC) migration works
Four steps, OpenText Service Request Center (SRC)-specific
Connect
OpenText Service Manager (which underpins SRC) supports REST API authentication via session tokens / Basic Auth issued through the Service Manager web tier. Specific OAuth or SAML flows depend on the deployed authentication backend. into OpenText Service Request Center (SRC). Scopes limited to read-only on the data we move.
Map
We translate OpenText Service Request Center (SRC)-specific structures (custom fields, objects, value lists) to the destination's model.
Sample
Test with a 50–200 record subset to validate OpenText Service Request Center (SRC) quirks before production.
Migrate
Full migration with OpenText Service Request Center (SRC) rate-limit handling. Rollback available throughout.
FAQ
OpenText Service Request Center (SRC) migration FAQ
Answers to the questions buyers ask most during OpenText Service Request Center (SRC) migration scoping. Not seeing yours? Book a call.
Can't find your answer?
Walk through your OpenText Service Request Center (SRC) migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationOther helpdesks we support
Ready when you are
Migrate OpenText Service Request Center (SRC).
Without the rebuild.
Free scoping call with a migration engineer. Tell us about your OpenText Service Request Center (SRC) setup and destination — written quote back within a business day.