Software modernisation companies: how to compare them, with a shortlist

Compare software modernisation companies on the product your customers will use after the change, as well as the technology that runs it. An established product has to feel current without breaking the habits customers rely on, and those decisions have to survive into code. At Tcules, we recommend one team that designs the change and builds it, including AI-enabled features: one team answerable from design decision to release. That is [how we work](#product-and-workflow-layer).

For product-experience work, from portal navigation and dense expert screens to back-office redesign, the team we recommend is ours. To compare other firms' cases of that work, see Eleken's portal case, Koru UX's healthcare EHR programme, The Skins Factory's expert-screen case and UXDA's back-office case. For engineering on a particular platform, DICEUS's insurance-platform case and ScienceSoft's client-led SaaS case are worth comparing too.

Where the main purchase is a specialist programme, we would choose the specialist:

• Retiring or incrementally replacing a mainframe: Slalom, from its La-Z-Boy case, or Thoughtworks, from its mainframe-seams article.
• Exiting data centres or moving a reporting and analytics estate: Accenture, from its MSRB case, or EPAM, from its food and beverage case.
• Converting legacy banking code with AI assistance: Globant, from its COBOL pilot.

We publish this comparison and include ourselves in it.

Five criteria for comparing software modernisation companies

This is the bar we hold every firm to, us included. Ask each firm to walk through one comparable project against these tests. Public cases help you begin; work shown under a non-disclosure agreement can answer the same questions.

1. Understand what customers rely on. Ask which workflows, shortcuts, saved views, records and permissions stayed stable, and which changed deliberately. Research should distinguish a useful habit from a workaround worth removing.
2. Improve the experience, including its finish. Look beyond before-and-after home screens. Ask to try a dense table, an empty state, an error and a keyboard path. Agree accessibility checks against WCAG and inspect hierarchy, legibility and interaction detail in the running product.
3. Prove a manageable first release. Ask for one complete workflow, its dependencies and the acceptance checks. If old and new must coexist, the plan needs reconciliation, rollback and a clear retirement point. A phased rollout is useful only if each phase can actually operate.
4. Keep design and build accountable to the same decisions. Name who owns interface behaviour, business rules, APIs, data changes, testing and releases. Ask to see a design choice carried into the code and checked after implementation.
5. Separate delivered work from outcome claims. A prototype, a release and a measured improvement are different evidence. Ask what reached users, what was measured, against which baseline, and who can confirm it.

When a firm quotes a result figure, ask for the baseline and method behind it.

Software modernisation companies at a glance

The shortlist starts from cases of established software, rather than general service catalogues. One case shows that a firm has done that kind of work, not that it is expert in every domain, and each firm may publish wider services. Use the evidence and status to choose whom to investigate, then use the question to test the proposed engagement. Each case status is taken from the cited case.

Turn the shortlist into comparable proposals

Give the firms you call the same first workflow and the same constraints. Include the users and roles it serves, the rules and integrations it touches, the habits that must survive, and the change you want customers to notice. Ask each firm to return:

• A first-release scope: what changes, what stays and what is deliberately outside it.
• An ownership map: named responsibility for research, design, code, security, data, testing, release and support.
• Acceptance checks: the tasks existing and new users must complete, alongside performance, accessibility and regression checks.
• A rollout plan: who moves first, how old and new coexist, how failures are reversed and when the old path retires.
• A commercial proposal on those assumptions: scope, dependencies, support and change control, so you can compare the same work.

If the uncertainty is still whether to preserve, redesign, replatform or retire, resolve that with the legacy-software decision framework first. For the detailed transition method, read how to redesign legacy enterprise software without upsetting users.

Established products redesigned and built: experience, code and release

Tcules: improve the product customers know, and build it

An established product has two audiences: the customer who can use it almost without looking, and the prospect comparing it with newer software. We design for both. The aim is a product that feels clear and current, with better interactions and visual craft, while retaining the habits that make daily work efficient.

We begin with the running product, its users and the evidence your team holds. That lets us decide where the product needs a better structure, where a careful interface redesign is enough, and where a new capability needs changes underneath. Design engineers try uncertain interactions in code early. Our software development then builds the agreed scope, with product design carried into engineering decisions: frontend and backend, APIs and integrations, and AI-enabled features. Acceptance criteria are declared before work starts, and each engagement states what remains client-owned at release. For AI features, we design how people ask, review and correct, then build the feature into the workflows customers already know. Our product modernisation services set out how that scope is agreed.

On Chestnut, a live producer performance platform that insurance carriers use to pay and inform their agents, we worked from the running application, its codebase and its product specs. We implemented the bonus designs directly, coded part of the communications frontend ourselves and reviewed built features against the designs as they landed. Building in the codebase also surfaced states the design files had not covered, and we added them as they appeared.

For Benchmark Gensuite, we began with the components every application shares, redesigned the heavily used scope selector, and tested the redesigned attachments interface as a coded prototype in working HTML, CSS and JavaScript, so stakeholders could review its behaviour. For Gold Image Printing, we shadowed staff, took a component-based approach and extended one style guide and design language across the online store and the ERP system. Working with Gold Image Printing's technical team, we ensured a smooth transition from design to implementation.

For release proof outside SaaS, The Chain Hut, an online retailer of silver chains and fashion jewellery, began with a UX audit and became a full e-commerce redesign. We designed and developed the result: a fully functional, optimised website built on the Magento e-commerce platform.

Bring to the first discussion: one workflow customers depend on, what frustrates them now, and what your product needs to do next. We can use it to define a first stage with something meaningful to try, and what each side will own.

Eleken: a satellite-communications portal made easier to navigate

Eleken's Network Innovations case describes a customer portal for monitoring and managing satellite and terrestrial communication terminals. The redesign replaced buried nested navigation with a sidebar and gave each role a homepage showing the data it needs. Users relied on a manual clustering toggle on the map, so it stayed even though the designer had proposed automatic clustering.

For the build, Eleken's product design engineering service delivers working frontend code built from your existing components, as pull requests in your repository with a preview for each. Your developers review it, connect the backend and deploy. Ask which backend and integration work your team would own, and how the hand-over into your release process works.

Koru UX: embedded design across a healthcare programme

Koru UX's cloud EHR case summary describes an embedded UX team supporting a four-year redesign and cloud migration across product and engineering stakeholders. It also describes an embedded transcription tool developed into a standalone AI product. The page offers the full case as a download.

Consider it when you are buying an ongoing healthcare UX practice across several workstreams. Read the downloadable case and ask about the people proposed for your engagement: how did they preserve clinician routines, agree priorities with engineering and check the released product?

The Skins Factory: hierarchy and detail in expert interfaces

The Skins Factory's FortifyData case shows a cybersecurity risk-management redesign organised around the questions security teams need answered. It combines risk information, analytics and workflows, uses contextual slide-in panels to keep users in place, and brings two risk-modelling screens together.

The case shows how the studio reorganised hierarchy and visual language in a dense expert interface. For the build, its site describes a development partner that takes approved designs to production software. Ask to see the implemented product, how expert users evaluated the changes, and who owns engineering and migration.

UXDA: banking back-office research and redesign

UXDA's ITTI Digital case follows the redesign of an established core-banking product as its vendor moved towards a cloud-based offering. Stakeholder interviews, research with banking employees and a user-journey workshop informed a continuous journey across previously fragmented functions.

The case is relevant to a bank or banking-software vendor rethinking employees' daily work. Ask how existing bank users move to the redesigned journeys and how training is planned.

Platform updates and engineering within your programme

These two cases cover engineering purchases: an insurance-platform technology update, and engineers added to a programme your team already leads. Both firms also publish design services, noted below. Whoever you hire, design and engineering scope that is shared needs shared acceptance checks.

DICEUS: insurance-platform technology and interface changes

DICEUS's INSIS case describes updating Fadata's insurance platform, with Oracle ADF, Angular and REST services involved. It includes a revised main menu and a Supervisor view for upcoming, unassigned and overdue tasks. Its stated aim includes preserving functionality without performance or quality regression.

DICEUS also publishes UI/UX design, legacy application modernisation, frontend, backend, full-stack and system integration services. For an insurer changing an established platform, this is a relevant application case. Ask the team to map the exact direction of the technology changes in your engagement and show the regression checks.

ScienceSoft: engineering within a client-led SaaS programme

ScienceSoft's supply-chain SaaS case describes engineers joining the client's team to modernise inventory and shipping interfaces. New React interfaces worked against an older backend through added endpoints. The work also included .NET and Azure services and changes to the integration-management interface.

This is a useful model when you have product and delivery leadership and need engineering capacity inside that programme. ScienceSoft also publishes SaaS UI design services, including redesign. Ask which decisions remain with your team, how interface quality is reviewed, and who owns support after each release.

Mainframe, infrastructure and data programmes

For a procurement centred on retiring a mainframe, moving data centres or transforming an organisation's analytics infrastructure, the specialist programme is the main purchase. These are situations where we would choose an infrastructure or enterprise-estate partner. Product experience can still be a coordinated workstream, with an explicit owner rather than an assumed consequence of migration.

Slalom: mainframe retirement with operational checks

Slalom's La-Z-Boy story describes working with AWS to map mainframe dependencies and plan a route to decommissioning. Its retirement condition is concrete: processing in the AWS environment must match the mainframe's output exactly. Slalom reports year-on-year mainframe cost avoidance as customer impact, and says shutting off the mainframe will reduce annual run costs.

Ask which workloads have passed comparison checks, what remains before retirement and who maintains the replacement.

Thoughtworks: finding seams for incremental replacement

Two Thoughtworks technologists describe a mainframe-displacement programme for a consumer-data business. They explain where new services could run alongside the mainframe and how outputs could be compared, using boundaries such as files, APIs and data interactions.

Consider the approach for a large system that needs to be replaced capability by capability, and ask for a reference that covers the production cutover.

Accenture: cloud migration, workforce change and support

Accenture's case for the Municipal Securities Rulemaking Board (MSRB), a US municipal-securities regulator, moves applications and databases to AWS in waves, with workforce learning and ongoing managed services. It then describes an application-modernisation roadmap and interface redesign for MSRB.org and EMMA, the regulator's market-transparency website. Ask what the managed-services agreement covers.

EPAM: reporting and analytics estate transformation

EPAM's food and beverage case consolidates legacy reports into Power BI data models and dashboards in three waves, and moves DB2 schema and SQL towards Snowflake. Ask how replacement dashboards are accepted and which data-governance responsibilities remain with you.

Globant: an AI-assisted core-banking conversion pilot

Globant's banking story covers a pilot for the Argentine subsidiary of an international bank, converting a COBOL module to Java microservices while keeping the original data storage. Ask about integration tests, data reconciliation and the maintainability of the generated code.