Modernization glossary

Defining data meaning, quality, authorization and usage boundaries for a specific AI task. Exposing an API or centralizing data alone is insufficient; the evaluation of correct and incorrect answers also needs to be defined.

A contract through which software exposes operations and data to other software. Authorization, errors, versions and retry behavior matter alongside request format; an API does not have to be a public internet endpoint.

A set of code, conventions and components that organizes an application and common tasks. Its version is distinct from the language or runtime version; target selection considers dependency and support compatibility together.

The ability of a new version to support specified older uses and contracts. Compatibility can differ for source code, binaries and behavior; it should not be assumed for every critical application workflow without testing.

A reference recorded before a change using a defined task, dataset, environment and method. Meaningful comparison requires comparable conditions and scope; another organization’s industry figure is not a baseline for your system.

A change that can require adaptation of previously working source, binaries or behavior. It need not cause a compiler error; silent differences in date formatting or query outputs also belong in acceptance tests.

Practices for regular code integration, automated checks and delivery or deployment. Continuous delivery is not identical to automatically releasing every change to production; approval and rollback boundaries need explicit definition.

Managing changes to database structures such as tables, columns, indexes or relationships through versioned, executable steps. If application versions coexist, schema compatibility and the risk of data loss during rollback require separate assessment.

A mechanism that treats a group of data changes as a defined unit, completed by commit or undone by rollback. The same boundary should not be assumed to carry automatically across separate services and databases.

A package, component, service or environment condition an application needs to build or run. Direct dependencies can introduce transitive ones; an upgrade plan reviews the chain rather than only the packages named by the application.

The end of a defined support period for a product or release under a particular provider. Active maintenance, security fixes and paid extensions can differ; read the date together with the product, version, provider and support type.

An operation whose repeated application has the same intended effect on system state as one application. It matters when retrying after network failures; payments and orders need explicit keys, records and duplicate-processing rules to achieve it.

A system still used by the business whose change or operation is constrained by technology, dependencies or knowledge. Age alone does not establish that it has no value or must be replaced.

A controlled exercise that observes system behavior under a defined dataset and workload. Record concurrency, duration, environment, failures and measurement method; capacity observed in a test does not automatically generalize to different production conditions.

A provider’s longer support policy for selected releases. Duration, scope and patch requirements vary by product; an LTS label does not imply indefinite security updates or support for the complete application.

The middle value of ordered observations, or the mean of the two middle values when the count is even. It can be less affected by an extreme value than the mean, but still needs a sample count and measurement conditions.

An architecture of services that can be developed and deployed around separate business boundaries. Networking, monitoring and data consistency add responsibilities; splitting an application into smaller parts does not by itself create business value.

Adapting a system’s technology, data, interfaces or operations to new needs while preserving required business outcomes. It can include an upgrade or incremental redesign; success is assessed against the business goals.

An application whose functionality is largely built and deployed together. A monolith with clear internal modules can be maintainable; a single deployment unit alone does not demonstrate poor quality or a scaling problem.

A pattern where an initial list query is followed by a separate related-data query for each record. Round trips can grow with the record count; choose a remedy after inspecting the required data and query plan.

An approach that maps application objects to relational database data. It organizes data access but does not remove the cost of generated queries; query counts and plans still need examination under relevant workloads.

The ability to investigate system state and behavior through signals such as logs, metrics and traces. Collection alone is insufficient; define workflow-related questions, access boundaries and responsibility for responding to findings.

The latency threshold that approximately 95 percent of observations do not exceed under the chosen percentile method. It helps examine slower-tail behavior; it is not the maximum, mean or a response-time guarantee for every request.

Evaluating old and new systems together within a defined scope and period. It enables output comparison but needs ownership, routing and synchronization rules to avoid processing or writing the same business operation twice.

A target for the acceptable amount of data loss expressed as time after a disruption. Backup or replication frequency affects it; stating the target does not prove it was achieved, so restoration and data validation are required.

A target duration for returning to a defined service level after disruption. Plan for verification of data, applications and workflows as well as infrastructure startup; an untested target is not an observed recovery time.

A plan to return to an acceptable working state after a failed or rejected change. Reverting an application package does not restore changed data; define executable conditions for code, schemas, messages and records separately.

The environment and execution components that run application code, such as a JVM or the .NET runtime. It is versioned separately from build tools and application frameworks, so migration checks each layer’s compatibility.

Executable logic defined and invoked within a database. It may contain business rules, data changes or batch operations; modernization must account for its behavior and consumers rather than moving table rows alone.

An approach that gradually transfers selected responsibilities from an old system to new components. Routing and data ownership stay explicit, and old components are retired after acceptance. Temporary dual-operation costs remain part of the plan.

A metaphor for the extra effort that shortcomings in a system’s internal structure impose on later changes. Older code does not carry equal cost everywhere; prioritize areas with concrete effects on frequently changed workflows.

The amount of work or number of requests completed per unit of time under specified conditions. Interpret it with latency, errors and resource use; accepting many requests does not establish that the same number completed correctly.