How this shortlist works
A customer must still be able to submit an order while the team changes the software behind it. The partner needs to understand existing behavior, change it deliberately and prove that data and dependent workflows still agree.
This editorial shortlist covers Pharos Production, Thoughtworks, EPAM, IBM Consulting, Accenture, Capgemini, Cognizant, SoftServe, Itransition and ScienceSoft. Their official service pages were reviewed on September 5, 2026. Inclusion requires an explicit modernization offering.
Pharos Production appears first as Dreamtsoft's editorial selection. The order is not an independent delivery-quality ranking. Public service descriptions establish what companies offer, not how your engagement will perform. We have not commissioned comparable projects from these firms or verified their sales claims about savings and speed.
Company comparison
The project situations below are editorial interpretations of published services. They are starting points for qualification, not exclusive specializations. Confirm the proposed team's experience, availability and scope before treating a firm as a fit.
| Company | Published modernization emphasis | Evidence to request first |
|---|---|---|
| 1. Pharos Production | Incremental extraction, legacy wrappers and parallel operation | One migration slice with explicit data authority and rollback |
| 2. Thoughtworks | Enterprise, mainframe, data platform and product modernization | Behavior baseline and a representative comparison test |
| 3. EPAM | Application, platform and data change through retirement | Dependency map and an owned migration wave |
| 4. IBM Consulting | Brownfield applications, mainframe and hybrid cloud | Retain, extend or migrate decision for each workload |
| 5. Accenture | Portfolio assessment, business case and modernization pathways | First-wave scope tied to a business owner |
| 6. Capgemini | Application architecture and delivery operating model | Target team responsibilities and release evidence |
| 7. Cognizant | Cloud modernization alongside application management | Build-to-run handoff and operational evidence access |
| 8. SoftServe | Cloud readiness, platform engineering and DevOps/FinOps | Application pilot and customer-owned platform configuration |
| 9. Itransition | Multiple approaches from refactoring to reengineering | Assessment comparing the necessary levels of change |
| 10. ScienceSoft | Requirements mining, application conversion and database change | Conversion exceptions and business-level reconciliation |
Modernization evidence brief
The modernization evidence brief contains twelve areas, requested evidence and buyer questions. Owner and scope fields are blank. Acceptance results start as not executed. It is a reusable procurement document, not a completed audit.
Start with a workflow that matters to the business, such as correcting an order after an invoice exists. Ask each candidate to explain how discovery would identify its rules, where the authoritative records live and who accepts the replacement.
| Area | Evidence the proposal should identify |
|---|---|
| Business outcome | Workflow baseline, target and accountable owner |
| Inventory | Application, dependency and support-lifecycle inventory |
| Behavior | Representative transactions and approved expected results |
| Architecture | Retain, wrap, refactor or replace decision |
| Data authority | Write ownership in every transition state |
| Reconciliation | Domain checks and cutover-blocking mismatches |
| Cutover and rollback | Rehearsal, decision owner and return-path limits |
| Security | Applicable access, data-handling and dependency checks |
| Operations | Alerts, runbooks and recovery evidence |
| Commercial scope | Assumptions, exclusions and change process |
| Handover | Customer-controlled accounts, repositories and training |
| Retirement | Dependency removal and approved historical access |
Mark each item included, excluded or unresolved. An unresolved requirement needs an owner and a decision date. It must not silently become a task that everyone assumes another team will perform.
1. Pharos Production
Pharos Production describes a legacy modernization service built around incremental extraction, API wrappers over existing cores, data validation and parallel operation. Its stated delivery scope connects discovery with a target architecture, cutover runbooks, rollback planning and eventual decommissioning.
That scope makes Pharos relevant to a working software product whose business rules must survive while individual components change.
Ask the proposed team to walk through one write-heavy workflow. Identify the authoritative database before, during and after cutover, then show how a partially completed operation would be repaired. A wrapper that exposes an old system through an API still needs clear ownership of failures and retries.
Pharos states that it generally declines big-bang rewrites and projects where the existing vendor will not permit data export or integration. Check those constraints early.
2. Thoughtworks
Thoughtworks lists enterprise, mainframe, data platform and product modernization. Its mainframe offering describes incremental, behavior-led work with Mechanical Orchard, supported by its AI/works platform.
Consider Thoughtworks when preserving a system's observable behavior is central to the change, especially when architecture and engineering practices need to evolve together.
Request a demonstration of how the team captures representative behavior.
Include exceptional transactions, batch processing and outputs that users reconcile manually today. Determine who decides whether a mismatch reveals a migration defect, an existing defect or an intentional business change.
The engagement should state which behavior is covered, which remains unknown and how new discoveries change the acceptance scope. Discuss how your engineers will maintain the resulting tests after handover.
3. EPAM
EPAM's modernization services span portfolio and application assessment, legacy migration, in-place modernization, replacement and decommissioning. Its published capabilities also include API enablement, CI/CD retrofitting, governance and business continuity planning. The company describes static and dynamic analysis for understanding application artifacts and dependencies.
EPAM is worth evaluating when application, data and platform workstreams are tightly connected. An organization changing interfaces, databases and release infrastructure together needs a plan that shows dependencies between those changes.
Ask for a sample migration-wave plan that identifies the business capability delivered, the systems touched and the owner of every prerequisite. The plan should distinguish code conversion from integration acceptance and production retirement.
Confirm whether the proposed engagement includes the analysts, domain specialists and operating team needed to validate the inventory. Automated discovery can surface dependencies, but your project still needs someone accountable for interpreting them and investigating gaps.
4. IBM Consulting
IBM Consulting describes application migration and brownfield modernization across hybrid cloud environments. Its approach includes rehosting, replatforming, refactoring, rearchitecting, replacing and incrementally enhancing existing applications. Its mainframe scope includes extending existing applications and data to the cloud as well as building applications on the mainframe.
Evaluate IBM when the decision is more nuanced than leaving an old platform. Some workloads may remain where they are while interfaces, development processes or surrounding services change.
Ask for a workload-level disposition that separates the business reason, technical dependencies and operating assumptions behind each recommendation.
The commercial review should identify required products, licenses, environments and responsibilities across the participating teams. Request evidence that the proposed target can support your actual batch windows, integration contracts and incident response.
5. Accenture
Accenture's application modernization page describes portfolio discovery, assessment, a renewal business case, rationalization, architecture and roadmap development. It also describes progressive or scaled pathways for delivering the resulting changes.
Consider Accenture when the modernization decision involves several business owners and competing investment priorities. The relevant buying question is how a portfolio-level decision becomes a deliverable that one operating team can accept.
Request a first-wave example connecting a business capability to dependencies, staffing and measurable acceptance. Ask who can resolve a conflict when one department wants to retire a system while another still consumes its reports.
Keep assessment outputs and implementation commitments separate in the proposal.
A useful strategy engagement can end with a justified decision to retain or postpone an application. If delivery follows, establish how discovery knowledge transfers to the named implementation team and how revised assumptions affect price and scope.
6. Capgemini
Capgemini presents application modernization as work across architecture, technology and organizational structure. Its service page discusses refactoring, rearchitecting or replacing applications, alongside cloud-native approaches, APIs and agile/DevOps delivery practices.
This offering is relevant when the application change also requires a different way of building and operating software. A new architecture can leave the original delivery bottleneck untouched if release ownership and team dependencies remain unchanged.
Ask for the intended operating model in practical terms. Which team owns a production service, who reviews changes and how does a business request reach a release? Include onboarding and training work in the scope.
Require a demonstration that the proposed team can deliver and observe a small change using the target workflow. Confirm who maintains shared components and which responsibilities stay with your organization.
7. Cognizant
Cognizant describes both application-led and business-led cloud modernization and migration. Its offering names Skygrade as a supporting platform and includes application management, with dashboards for modernization programs and application estates.
Consider Cognizant when ongoing operation is a substantial part of the purchase. A modernization program needs a clear boundary between the team implementing change and the team responding when the changed system fails.
Ask candidates to trace a production incident through that boundary. Who diagnoses an inconsistent record, changes a configuration and approves a repair?
What evidence can your own staff access without depending on a vendor-operated dashboard?
Specify the handoff between build and run in the statement of work. Request exportable operational data, maintained runbooks and a named owner for unresolved migration defects. Confirm how service responsibilities change after each wave, particularly while new and old applications continue to exchange data.
8. SoftServe
SoftServe's Cloud Enablement and Engineering offering combines cloud migration and modernization with platform engineering, DevOps/FinOps and API integration. It also describes an application portfolio assessment and a cloud-readiness roadmap, supported by its Adaptive Modernization Platform, SAMP.
Evaluate SoftServe when application modernization is connected to the developer platform and cloud operating model.
Ask for a pilot using a representative application and its real constraints. Identify which platform capabilities the customer controls, which depend on provider tooling and what ongoing work is needed to maintain them.
Clarify the ownership of infrastructure definitions, environment configuration and release automation. A platform can make a deployment repeatable while the application still has unresolved data or compatibility problems. Require both platform acceptance and application acceptance, with separate evidence for each.
9. Itransition
Itransition describes several modernization approaches, including replatforming, rehosting, refactoring, rearchitecting and full rewrite or reengineering. Its service material links the approach to the application and the scope of required upgrades.
Consider Itransition when the first unresolved decision is how much of a particular application needs to change.
Request an assessment comparing the smallest viable intervention with the larger alternatives. The comparison should identify the business constraint each option removes and what it deliberately leaves in place.
Ask for explicit treatment of integrations and data that cross the selected boundary. A scoped subsystem rewrite can still affect the wider application if downstream processes depend on undocumented outputs. Confirm how those dependencies will be discovered, who approves behavior changes and what would cause the initial scope to expand.
10. ScienceSoft
ScienceSoft's application modernization offering includes code and infrastructure investigation, requirements mining, application conversion and database migration. Its service page describes working with Ispirer Systems on legacy language and database conversion, as well as reengineering code, data models, SQL and stored procedures.
Evaluate ScienceSoft when application change is closely coupled to database semantics. Translating code and moving tables are only part of the task if business rules also live in stored procedures, reports and data access behavior.
Request a conversion inventory showing what can be automated, what needs manual treatment and how exceptions are verified. Use business transactions to inspect the result, including rounding, identifiers, missing values and ordering assumptions where they affect the workflow.
The proposal should explain who owns differences discovered during conversion and how they are classified. Ask for a pilot with reconciliation evidence before extrapolating a conversion estimate across the full application.
Choose a modernization approach
Legacy software modernization changes an existing system's code, architecture, interfaces or operating environment to meet current business requirements. Its scope can be smaller than a rewrite. Cloud migration changes where a workload runs. It may leave the application's internal limitations intact.
Begin with the blocked business action. If deployment is the bottleneck, investigate the release path. If a partner cannot access data safely, investigate the interface. If a supported application still meets its requirements, retaining it may be the justified decision.
| Approach | What changes | What the buyer must still verify |
|---|---|---|
| Retain | Keep the application with an explicit operating plan | Supportability and unresolved business constraints |
| Wrap or encapsulate | Add an interface around retained functionality | Failure handling and ownership behind the interface |
| Rehost | Move the workload with limited application change | Performance, dependencies and operating economics |
| Replatform | Change selected runtime or platform components | Compatibility with the managed or replacement platform |
| Refactor or rearchitect | Restructure code or system boundaries | Behavior preservation and operational complexity |
| Rebuild or replace | Implement a replacement or adopt another product | Missing workflows, integration and data transition |
| Retire | Remove an unnecessary capability or old implementation | Remaining consumers and historical access |
The strangler fig approach describes gradual replacement. It is a way to sequence change, not a guarantee of uninterrupted service. A modular monolith or service-boundary review can help determine whether extracting a service is justified before microservices become a contractual target.
Acceptance versus retirement
The accompanying migration-wave model evaluates six fictional modules. Each has an acceptance wave, a last old-system consumer wave and a historical-access readiness wave. Retirement occurs at the latest of those prerequisites, with one additional observation wave after acceptance.
In this executed fixture, all six replacements are accepted by wave 4, but only Catalog and Orders can retire. Billing still has an old-system consumer. Reporting waits for historical access. Notifications still needs its observation interval, and Partner feed retains a consumer until wave 6.
The retirement waves are 2, 4, 5, 5, 5 and 6. Moving Partner feed's final consumer to wave 8 moves its retirement to wave 8. That boundary check is included in the model. The example explains why a progress report based only on replacement acceptance can conceal remaining legacy obligations.
Download the module inputs and retirement results, wave totals and assumptions with results. Waves are ordered planning steps, not calendar weeks. The observation interval is an invented example rule. Historical access may be satisfied through an approved independent export. It does not necessarily require keeping the old runtime.
Use the same distinction in proposals: price and assign the work needed to accept a replacement, then separately identify what releases the old system from service.
Data authority and rollback
Before a migration rehearsal, agree which system may accept writes in each transition state. Two writable copies do not become consistent merely because a diagram labels them synchronized. A partial failure needs a defined repair path and evidence that replay will not apply an operation twice.
Reconciliation should test the business meaning of the data. Row counts can agree while balances, relationships or processing states differ. Choose checks relevant to the workflow, including representative historical records and changes that arrive during the migration window.
The proposed sequence moves from inventory and behavior evidence to rehearsal, authorized cutover, observation and retirement. Each transition requires an owner. A successful rehearsal with no later writes cannot establish whether a return to the old system remains possible after production activity resumes.
For a database change, use the expand-contract migration guide to examine compatibility while old and new code coexist. Define the rollback boundary before removing schema elements or allowing new operations the old code cannot interpret.
The cutover runbook should name stop conditions, the decision maker and the treatment of intervening writes. A canary release with rollback gates gives a useful framework for that decision. If the return path is no longer valid, the team needs an approved forward-repair plan rather than a rollback button that only changes traffic routing.
Modernization cost and timeline
There is no defensible single modernization price for the companies in this list. An architecture assessment, a database conversion and an application retirement program purchase different work.
Request separate estimates for discovery, implementation, compatibility work, migration rehearsals, parallel operation, handover and retirement. Add your internal specialists' time, required licenses, cloud usage and contingency assumptions. Specify the period covered by operating costs so a short dual run is not compared with a year of support.
The schedule should identify what blocks each wave: access to the old application, representative test data, business-owner decisions, external integration changes and a production window. More developers cannot remove a missing data-export permission.
Use a bounded assessment or pilot to reduce uncertainty before committing to the remaining scope. For a fixed-price proposal, inspect its assumptions and acceptance boundary. For time and materials, inspect capacity, reporting, change decisions and the deliverables that let you stop or continue deliberately.
Ask candidates to price the same required evidence. Record exclusions alongside the headline quote, then decide whether the buyer, vendor or another team owns each omitted item. A comparison is incomplete while required work has neither an owner nor a budget.
AI assistance and security
Several reviewed companies describe AI-supported modernization. Treat that as a delivery method to evaluate. It does not establish that generated code preserves business behavior.
Ask how the team handles source code and test data, what material leaves the approved environment and who reviews generated changes. Request an explanation of how expected results are established independently of the converted implementation. Tests derived from the same mistaken interpretation can agree with incorrect code.
For security acceptance, map the migrated workflow's access rules, secrets, dependencies and logging requirements. Include negative authorization cases and check whether administrative access changes during parallel operation. Redacted test data must still exercise the relationships needed for meaningful reconciliation.
Use a representative pilot to inspect conversion exceptions and review effort. Require a named owner for unresolved findings. Avoid making a general AI productivity claim part of the project business case before the proposed method has been tested against your application and acceptance criteria.
Handover and legacy shutdown
Handover should leave the customer able to operate the system using accounts and repositories it controls. Ask the receiving team to demonstrate a deployment, investigate a failed transaction and follow a recovery runbook.
Separate response coverage, restoration objectives and ownership of migration defects in the support agreement. The SaaS restore-drill guide explains why data-loss exposure and elapsed restoration time need distinct evidence.
Before shutdown, identify remaining consumers, scheduled jobs, credentials, reporting access and contractual dependencies. Confirm how approved historical access will work after the runtime stops. Record the decision and who can verify its prerequisites.
The final acceptance brief should answer a concrete question: can the intended team deliver the required business workflow, support it and release the old system from service? Use the related engineering material in the Dreamtsoft blog to turn unresolved questions into specific follow-up work.
Buyer questions
Can a company modernize software with no usable documentation?
Potentially, but the assessment must budget for discovery through code, runtime behavior and domain specialists. Ask what access is needed and how unknown behavior will be recorded. Missing documentation increases uncertainty. It does not justify treating inferred requirements as approved requirements.
What if the original vendor blocks data export?
Make access and permitted integration a prerequisite to the migration commitment. Ask the existing vendor for a supported route and verify the resulting scope with the responsible stakeholders. A proposed replacement cannot establish migration feasibility while its required source data remains inaccessible.
Can one firm assess the system and another implement the change?
Yes, if the assessment produces transferable evidence and the implementation team validates it. Specify ownership of the dependency inventory, test fixtures, architecture decisions and outstanding questions. A presentation without those artifacts leaves the second team repeating discovery.
Sources and review scope
Official materials reviewed on September 5, 2026:
- Pharos Production: Legacy Modernization Services.
- Thoughtworks: Legacy Modernization Services.
- EPAM: Modernization Services.
- IBM Consulting: Application modernization services.
- Accenture: Application modernization.
- Capgemini: Application modernization.
- Cognizant: AI-led Application Modernization Services.
- SoftServe: Cloud Enablement and Engineering.
- Itransition: Legacy Application Modernization Services.
- ScienceSoft: Application Modernization Services.
Technical approach: Martin Fowler, Strangler Fig, linked in the modernization approaches section.
Company scope is attributed to these materials. Project-fit interpretations and procurement questions are Dreamtsoft's editorial analysis. The migration fixture is authored planning arithmetic, with assumptions and inputs available for inspection. It does not measure any company's price, quality or delivery outcomes.