Our Methodology

Research Approach

We publish decision frameworks and market intelligence for software modernization. Linked technical documentation can support a mechanism or product capability; it cannot establish what projects cost, how long they took or how often they succeeded. A measured benchmark needs its own project-level evidence and reproducible calculation.

The requirements below describe what a supported benchmark must disclose. They do not certify that every existing figure on the site meets those requirements. A page review date records an editorial check, not the dates of the projects or a live pricing update.

Data Sources and Their Roles

Customer disclosures, procurement records and post-implementation reports can provide project observations when scope and dates are clear. Vendor case studies are labeled as vendor-reported and may have selection bias. Multiple publications about one engagement do not create multiple independent projects.

Analyst surveys provide context about their defined respondent population. Technical documentation supports capabilities and implementation guidance. Neither source class becomes a project-cost or outcome cohort without appropriate underlying observations. Licensed or private records require publication rights; an anonymized appendix must still provide enough evidence to reproduce the claimed metric.

Benchmark Provenance: Three-Cohort Review

Reviewed 30 September 2026. Project-level records were not available in the materials reviewed for the three pages below. No cohort dates, inclusion rules, deduplication keys, metric-specific denominators or calculation versions could be established. Private records may exist elsewhere; their existence and accuracy were not verified. As of 6 October 2026, project-cohort figures (project counts, median costs and timelines, and success rates) have been withdrawn site-wide from migration and service pages, including the site-wide verified-project total. The cost and timeline ranges that remain are editorial scoping ranges, not measured cohort statistics or supplier quotes.

The revised source pages withhold the unsupported benchmark fields and link technical sources for the guidance they actually support. Explicitly labeled financial examples are hypothetical calculations with stated inputs. No replacement cohort, confidence interval or verified-project total is inferred from legacy aggregate values.

Requirements Before Publishing a Cohort Benchmark

A supported claim needs the following disclosures alongside a linked, rights-safe evidence appendix. These are publication requirements, not assertions that missing historical records have been reconstructed.

1. Cohort dates and eligibility: State the project period, geography, industry, size and stage. Define the unit of analysis and inclusion/exclusion rules before calculation. Report planned, in-progress and completed projects separately; record missing values rather than replacing them with estimates.
2. Sources and deduplication: Assign a stable engagement ID and map each observation to its source. Merge repeated disclosures of the same project and document exclusions. A project may inform multiple paths, but counts within a path and metric must be deduplicated; path counts must not be summed as unique projects.
3. Metric definitions and currency: Define cost coverage, timeline start/end events and outcome criteria. Retain original currency and basis year; disclose any FX date, rate source and inflation adjustment. A usable sample size belongs to each metric. Unknown or incomparable outcomes must be disclosed, with an explicit numerator and denominator for any outcome percentage.
4. Aggregation and uncertainty: Link observation IDs and a versioned calculation. A median is the middle ordered point observation (the mean of the two middle values for an even count); do not turn reported ranges into undocumented midpoints. Label observed minima/maxima separately from percentiles and scenario bounds. Disclose missingness, exclusions, source concentration and scope variation; quantify uncertainty only when the data and method support it.
5. Reproduction and corrections: Publish an evidence appendix with allowed source links, metric-specific observations or a rights-safe reproducible projection, definitions, calculations, review date and release identifier. Retain corrections and prior claims with their status. If disclosure or source quality prevents reproduction, label that limitation and withhold or qualify the unsupported claim.

How to Read the Figures

A sourced observation, a cohort statistic and an illustrative scenario are different evidence types. A vendor-reported cost is a claim from that source, not an independent estimate of the market. A forecast is not realized savings, and a price range in research is not a supplier quote.

Simple payback divides incremental investment by net savings using the same period. It excludes discounting and does not capture benefit ramp-up, financing or retained costs unless those are explicitly modeled. The cloud and COBOL examples now state their hypothetical inputs and correct the earlier arithmetic.

Vendor profiles use publicly observable information — published case studies, team size, geographic presence, technology specializations and client references.

Claim-level supplier evidence and the registry attributes of every vendor profile are published as an open dataset, with its field dictionary, inclusion rules and verification status: Modernization vendor evidence dataset.

We currently have no sponsors. Vendor inclusion, recommendations, and highlights are editorial decisions based on documented evidence. Featured vendors on migration and service pages reflect documented expertise in that specific path or service.

Limitations and Review Scope

Published outcomes can overrepresent successful projects. Differences in scope, region, date, source independence and reported cost categories can make cases incomparable. A large claimed sample does not fix missing provenance.

The project-level review covers Cloud Modernization Research, Cloud Readiness Assessment and COBOL to Java. The cohort figures on the remaining migration and service pages were withdrawn on 6 October 2026 rather than validated; nothing new was verified, and supplier claims are not validated by this review. The linked pages contain their own evidence-status appendices; no project-level dataset was reconstructed.

Cloud pricing, licensing and labor rates change. Recheck current terms when building a business case. Editorial review dates cannot substitute for a cohort window, currency basis year or source access date.

Updates and Corrections

An evidence review should record which sources and calculations were checked, which claims changed and which remain unresolved. Quantitative fields should be reinstated only after the relevant records and calculation can be inspected. A correction to a formula does not validate the assumed inputs.

Aggregate pages are built from our maintained path data. A source correction counts as published only once the live page and its structured data show it; an edit to the source alone does not establish that.