Our Methodology
How Software Modernization Intelligence distinguishes sourced guidance, measured benchmarks and illustrative models — publication requirements, evidence status and limitations.
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 repository 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.
| Page | Previous cohort claim | Review outcome |
|---|---|---|
| Cloud Modernization Research | 200+ cloud migration projects (unverified) | Not reproducible from available records; measured benchmarks withheld |
| Cloud Readiness Assessment | 340 engagements (unverified) | Not reproducible from available records; measured benchmarks withheld |
| COBOL to Java | 127 projects (unverified) | Not reproducible from available records; measured benchmarks withheld |
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.
- 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.
- 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.
- 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.
- 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.
- 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.
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.
This review covers Cloud Modernization Research, Cloud Readiness Assessment and COBOL to Java. It does not validate the remaining migration, service or supplier cohorts. The linked pages contain their own evidence-status appendices; no project-level dataset was reconstructed during this review.
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 draw from stored path data. Source corrections must be synchronized before their rendered values and structured data can be verified; a local content edit alone does not establish production parity.