Brownfield AI Existing Software

Brownfield software is an existing system you are extending or changing. It might be an older CRM, an internal portal, or a recently launched SaaS application. Existing software does not automatically need replacement, and brownfield does not always mean obsolete.

Two related activities are often discussed together:

The first is the main focus here. The second, AI-assisted legacy modernization, can support delivery but does not by itself turn the product into an AI application.

Similarly, AI modernization is not a promise to replace every old component. It can mean improving a specific workflow while retaining the parts of the platform that still meet its requirements.

If a brief describes the goal only as “AI legacy software” or “LLM legacy application integration,” convert that description into a defined capability. LLM means large language model: the model may generate or interpret language, but the project still needs an authorized workflow and an observable result.

A prototype is useful evidence that an approach is worth investigating. Its limitations need to be explicit.

The point of the demo is learning. The point of the integration is delivering a dependable capability within the existing product’s responsibilities.

1. Business meaning is distributed across the system

A field named ready might describe warehouse packing, not permission to dispatch an order. A status displayed in the UI may depend on application logic, a scheduled job, or an external update.

These are illustrative examples, but the engineering issue is concrete: reading a database schema does not establish every business rule.

Before starting an AI legacy software project, trace one relevant workflow from user input to final result. Include validations, database-side logic, integrations, background work, and the people who interpret exceptions.

Salesforce’s discussion of brownfield development highlights the importance of existing automation, sharing rules, integration boundaries, and the reasoning behind architectural choices.

Practical implication: Have a domain owner confirm what the records mean. Where a rule must always hold, enforce it in application or service logic and test it. Do not rely on the model to reconstruct an undocumented rule from scattered examples.

2. The data needed for an answer may have different authorities

An AI feature might need current account data, historical transactions, and an approved policy document. They serve different purposes.

The live application establishes current operational state. A policy explains how to interpret it. A cached extract may be useful but represent an earlier moment.

For each input, record its source, meaning, owner, version or timestamp where relevant, and permitted use. Decide which source takes precedence when records conflict, and what the feature should do when required evidence is missing.

Practical implication: A vector index should not silently become the authority for rapidly changing transactional facts. When a task requires current status, retrieve it through an appropriate authorized interface or a replica with defined consistency and freshness guarantees.

Microsoft’s agentic behavior guidance separates authoritative knowledge, current evidence, and memory. That distinction also matters for a simple AI assistant inside an existing application.

3. Existing permissions must survive the new retrieval path

The old screen may restrict users to particular customers or branches. An AI feature can undermine that boundary if it uses a service account or search index with broader access and passes unrestricted results to the model.

Derive identity and access context from the authenticated request. Apply the required tenant, user, and record restrictions before protected information enters the model context.

Microsoft’s secure multitenant RAG architecture explicitly describes authorization-aware retrieval and filtering before grounding data is passed to a model. RAG, or retrieval-augmented generation, supplies relevant information to a model at request time.

Practical implication: “Only answer about this customer” in a prompt is not an access-control mechanism. Test denied requests and cross-tenant cases. Also account for permissions when reusing cached answers, exposing source links, and retaining traces.

Map which data reaches each new component, including the model service, retrieval store, caches, and monitoring system. Check processing, access, and retention settings against the feature’s requirements. The existing application’s controls do not automatically govern these additional data paths.

4. Copied data introduces another synchronization responsibility

Building a search index is only the first step. The integration needs a policy for changed records, deleted content, revoked access, and failed ingestion.

Treat freshness as a requirement of the particular task. A monthly reference guide and a fulfillment-status query can tolerate different update delays.

For example, Azure AI Search documentation explains that reindexing new and changed documents does not, by itself, remove orphaned documents whose sources have disappeared. Deletion handling needs its own supported mechanism.

Practical implication: Test updates, deletions, and access revocation, not just the initial import. Check how your chosen platform detects each change. If the feature cannot establish that its evidence is sufficiently current, define an abstention, refresh, or manual-review path instead of presenting certainty.

5. Model output enters interfaces built for different assumptions

Existing code may expect a valid enum, identifier, amount, or state transition. Generated output may be incomplete, unsupported, or inconsistent with the current record.

Use output validation appropriate to the destination. Checking a schema establishes structure, not factual correctness, authorization, or business validity.

Treat proposed changes as proposals. Recheck permissions, permitted fields, business conditions, and current record state in the executor before applying them. Preserve existing validation and approval paths where they remain authoritative.

OWASP’s guidance on improper output handling addresses the risks of passing model output into downstream systems without suitable validation and handling.

Practical implication: Avoid using generated text directly as executable SQL or trusting it as safe HTML. Use the relevant query and rendering safeguards. A convincing explanation cannot authorize a write operation.

6. AI becomes another dependency in a live workflow

A feature can produce a good answer and still cause a poor product experience if it blocks a critical screen, exhausts shared resources, or repeatedly calls an unavailable service.

Define latency and resource budgets for the complete request. Decide whether generation belongs in an interactive path or a background job, and establish timeouts, cancellation, and appropriate failure isolation.

For optional assistance, keep the established non-AI workflow available when the feature is unavailable. If the AI capability is essential to the task, define a genuine fallback or manual process rather than silently substituting an unverified result.

Microsoft’s circuit-breaker guidance describes protecting systems from excessive calls to failing dependencies and also identifies situations where the pattern adds unnecessary complexity.

Practical implication: Choose resilience mechanisms for the workload. A separate service, queue, or circuit breaker can be useful, but none is automatically required because the feature uses AI.

Before selecting a model or framework, write down the capability and the constraints it must respect.

This is a suggested scoping aid, not a standardized readiness score.

An AI legacy codebase review should combine repository inspection with workflow observation and domain input. Code can reveal behavior; it may not explain why that behavior is required.

The brief also gives a founder or consultant a way to compare proposals. An estimate should explain which existing dependencies were examined and which assumptions still need validation.

For AI integration, legacy systems require an approach matched to the capability being added. A document assistant and an agent authorized to update inventory need different boundaries.

An adapter can translate existing representations into a clear interface without forcing the model to understand every internal detail. Microsoft’s anti-corruption-layer pattern describes this separation between systems with different models or semantics. It also notes added latency and maintenance responsibilities.

When functionality is being replaced, the strangler fig pattern provides an incremental coexistence approach. For changes deeper inside a monolith, branch by abstraction can introduce an interface that supports old and new implementations.

These patterns are options for particular changes. Adding one AI feature does not, by itself, justify a microservices migration or a complete rewrite.

Consider a hypothetical order-management system used by several branches of a retail business. It has accumulated application logic, scheduled courier updates, and branch-specific access rules.

The requested feature is simple: an operations user asks why a particular order has not been dispatched.

The demo uses a prepared order export and generates a clear explanation. The live integration needs more context:

• ready means warehouse packing is complete, while a separate rule controls dispatch eligibility.
• The order has several shipments, with different states.
• Courier information has a recorded update time.
• The user may view only orders from authorized branches.
• An old policy document describes a rule that has since changed.

These details are invented to illustrate the design problem; they are not a Devine Globe client story.

Define a limited first release

Evaluate the real exceptions

Test partial dispatch, canceled orders, missing updates, conflicting policy versions, and branch-restricted records. Confirm that the explanation distinguishes recorded facts from assumptions and does not invent a dispatch promise.

Display relevant source timestamps or freshness notices where they affect the user’s decision. An answer can accurately describe an earlier snapshot while being unsuitable for a present-tense operational question.

Also test the original screens with the assistant disabled and its dependency unavailable. Success includes preserving the application’s established workflow, not just generating a useful paragraph.

If the team later adds action-taking, that is a material scope change. It needs explicit authorization, validation, approval, and recovery design; it is not simply another prompt instruction.

Brownfield integration needs evidence for both sides of the change.

AWS’s guidance on hardening generative AI applications combines traditional unit, integration, and end-to-end tests with AI quality evaluation.

Use that distinction to build targeted coverage:

For RAG, distinguish the retrieval problem from the generation problem. Microsoft’s RAG evaluation guidance separately assesses retrieved information and answer qualities such as grounding and relevance.

Grounding is not an independent guarantee that the source is correct or current. Confirm source authority and evaluate complete task requirements.

Retrieved documents can also contain instructions that attempt to influence the model. OWASP notes that RAG and fine-tuning do not fully mitigate prompt injection. Enforce access and action boundaries in code, and include adversarial cases appropriate to the feature.

After preproduction validation, introduce the feature to an appropriate limited cohort. Select the cohort according to the intended workflow and risk, rather than using a universal rollout percentage.

Google’s SRE guidance on canary releases describes exposing a change to part of a service population, evaluating it, and using the results to guide the rollout.

Track both the AI feature and the host application’s behavior. Useful signals include task completion, unsupported answers, human corrections, end-to-end latency, errors in existing workflows, and resource consumption.

Where suitable, evaluate proposals without displaying or executing them before exposing the feature to users. Such testing still needs authorized data use and must not accidentally perform business actions.

Define when to pause or disable the capability. A feature flag can stop future use, but disabling the feature does not automatically remove retained data or reverse earlier business changes.

Keep an operational owner and a support path in place as adoption grows. Passing a demonstration is not evidence that every user group or workload is ready.

A useful estimate makes the enabling work visible:

Not every project needs equal investment in every workstream. A well-documented API and a bounded read-only feature may need relatively little enabling work. Missing access controls or an unreliable source may require a separate repair first.

Avoid estimates that assume a working demo has already resolved these questions. Conversely, do not accept a complete rewrite as a prerequisite without evidence that a narrower change cannot meet the requirements.

AI tools can support code investigation, documentation drafts, test suggestions, and proposed refactoring. These outputs remain hypotheses or proposed changes until validated.

GitHub’s responsible-use guidance for Copilot warns that explanations may be inaccurate or incomplete and generated code needs review and testing.

Give engineering assistants relevant repository context, constraints, and acceptance cases. Keep proposed changes reviewable, and confirm behavior through tests and domain review. Compilation alone does not establish that an old approval rule, integration contract, or edge case has been preserved.

Using AI to accelerate engineering and adding AI to the product are separate decisions. Either can be useful without requiring the other.

Pause the affected integration when the team cannot establish necessary access boundaries, identify the authoritative data, or verify consequential behavior.

The next step may be small: document one state mapping, add a permission-aware read interface, or repair an ingestion process. It may also require more substantial modernization if the system cannot support the intended capability within acceptable constraints.

The deciding evidence should be specific. “The application is old” is not a sufficient diagnosis. “We cannot enforce branch-level access through the available interface” identifies a problem the project must resolve.

Brownfield AI becomes a clearer engineering project when the team identifies the user task, the authoritative evidence, and the behavior that must remain intact.

The first deliverable should be a credible integration plan: what the AI will do, what remains under application control, how the team will verify it, and who will operate it after release.

At Devine Globe, our AI integration, LLM and RAG development, and software modernization services can support teams extending existing products. If you are considering an AI capability for a live application, share the workflow, current system, and intended outcome with our team.