Migrate from LangChain to Production AI Agents

A LangChain prototype can impress stakeholders and succeed in a demo. The next question is when it can ship to real users.

That's when things get complicated. Moving a framework project to production means solving problems around isolated execution, concurrency control, deployment pipelines, observability, cost tracking, and retries. Connic puts those layers around an agent so the team can focus on the product instead of building a platform.

This guide walks through migrating an existing LangChain or ADK project to Connic, a managed platform that handles the production concerns for the team. Reusable Python tool logic usually stays the same; the structure around it changes.

Why Teams Outgrow Frameworks

LangChain, CrewAI, and Google ADK are agent frameworks. They provide abstractions for defining agents, tools, and chains. LangChain now also offers LangSmith Deployment, a managed runtime with observability and evaluation. Connic is the alternative for teams that want declarative agents, plain Python tools, managed connectors, guardrails, approvals, cost tracking, and deployment in one workflow.

Connic removes the following work from the production backlog around agent code:

The migration does not abandon existing agent logic. It moves that logic into an environment that handles production concerns instead of requiring a platform build from scratch.

Further reading: AI agent deployment platforms, observability.

What Changes (and What Does Not)

The important thing to understand: plain Python tool logic is usually reusable. A function that queries a database is still a Python function that queries that database. What changes is how agents are defined and how the project is structured.

Before and After

A LangChain support agent with two tools provides a concrete example.

from langchain_openai import ChatOpenAI
from langchain.agents import create_react_agent
from langchain.tools import tool

@tool
def search_docs(query: str) -> str:
    """Search the documentation for relevant articles."""
    # Your search logic here
    return results

@tool
def create_ticket(summary: str, priority: str) -> str:
    """Create a support ticket in the system."""
    # Your ticket creation logic here
    return ticket_id

llm = ChatOpenAI(model="gpt-4o")
agent = create_react_agent(
    llm=llm,
    tools=[search_docs, create_ticket],
    prompt="You are a customer support agent..."
)

After migration, this becomes two files: a YAML config and a tools module.

version: "1.0"
name: support-agent
description: "Handles customer support queries"
model: connic/gpt-5.6-terra  # or openai/gpt-5-mini with OpenAI BYOK configured
system_prompt: |
  You are a customer support agent. Search the docs first,
  then create a ticket if the issue cannot be resolved.
tools:
  - support.search_docs
  - support.create_ticket
retry_options:
  attempts: 3
  initial_delay: 10
  max_delay: 30

def search_docs(query: str) -> str:
    """Search the documentation for relevant articles."""
    # Same logic as before - no changes needed
    return results

def create_ticket(summary: str, priority: str) -> str:
    """Create a support ticket in the system."""
    # Same logic as before - no changes needed
    return ticket_id

Notice what happened: the tool functions are identical. Decorators are gone, the model and prompt moved to YAML, and the agent definition is now declarative configuration instead of imperative code.

Automated Migration with the CLI

For projects with many agents and tools, the Connic CLI includes a migrate command that automates the structural conversion. It scans the project's Python code, extracts agents and tools, and generates a Connic project with the correct structure.

$ pip install connic

$ connic migrate --source ./my-langchain-project --dest ./my-connic-project

  Scanning source project...
  Framework: langchain
  Agents found: 3
  Tools found: 8

  Generated Connic project in ./my-connic-project
  Running validation...

  Migration complete
    Project: ./my-connic-project
    Report:  ./my-connic-project/MIGRATION_REPORT.md

The CLI automates the structural work:

What Migrates Automatically vs. Manually

Some parts require manual migration. The realistic breakdown is:

Automatic

• Agent definitions (create_agent, create_react_agent, LlmAgent, SequentialAgent)
• Tool functions (decorators stripped, logic preserved)
• System prompts extracted from function arguments
• Model name detection and normalization
• Cross-file imports and tool dependencies
• Requirements.txt generation from source dependencies

Manual Review Required

• Complex orchestration workflows: LangGraph state graphs, parallel execution, and conditional routing need to be restructured as sequential agents or custom tool logic
• RAG pipelines: retrieval chains should be converted to use the built-in retrieval or reimplemented as tools
• State and memory: checkpointers and custom stores should be replaced with persistent sessions or the managed database
• Callbacks and hooks: framework callbacks should be converted to middleware
• Tracing integrations: remove LangSmith or custom tracing code once built-in Connic observability replaces it

The Connic Project Structure

After migration, the project follows a clean, opinionated structure. The same structure applies to migrated and new projects:

my-project/
├── agents/              # YAML agent configurations
│   ├── support.yaml
│   └── classifier.yaml
├── tools/               # Python tool functions
│   ├── support.py
│   └── classify.py
├── middleware/           # Before/after hooks
├── guardrails/          # Custom safety checks
├── schemas/             # Output schemas
└── requirements.txt     # Dependencies

The key difference from framework projects: configuration is separated from logic. Agent definitions are declarative YAML, tool logic is plain Python. No framework boilerplate, no runner scripts, no deployment configuration to maintain.

What Teams Get After Migration

Once a project is migrated, our platform handles the production concerns:

Step-by-Step Migration Checklist

Whether a team uses the automated CLI or migrates manually, the process looks like this:

1. 1

   Run the migration: connic migrate --source ./your-project --dest ./connic-project

2. 2

   Read the migration report. Address every follow-up item in MIGRATION_REPORT.md

3. 3

   Verify agent configs. Open each YAML file in agents/ and confirm the system prompt, model, and tool references

4. 4

   Check tool imports. Make sure functions in tools/ have all their dependencies

5. 5

   Remove framework code. Delete superseded LangSmith integrations, custom runners, and deployment scripts

6. 6

   Restructure complex patterns. Convert RAG pipelines to retrieval tools, callbacks to middleware, state to sessions

7. 7

   Develop and test. Run connic lint, iterate with connic dev, and run connic test if the project has a declarative test suite

8. 8

   Deploy. Run connic deploy or push to the connected Git repository

What Changes After Migration

Migrating from LangChain or ADK does not require rewriting the agents. Reusable tool logic usually stays the same. What changes is the infrastructure around it: deployment, observability, retries, guardrails, and integrations that Connic supplies from the first run.

The automated CLI handles the structural conversion and the migration report identifies what still needs manual attention. Complex graphs, persistence, retrieval, and external integrations naturally need more review, but the work starts from a converted project instead of a blank one.

For detailed migration guides, check the LangChain migration docs or the ADK migration docs. For a new project, the quickstart guide shows the end-to-end setup.