Migrate from LangChain to Production AI Agents

Your LangChain prototype works. It impressed the stakeholders, the demo went great, and now someone has asked the question: "When can we ship this 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 your agent so your 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 you. The key insight: reusable Python tool logic usually stays the same. What changes is the structure around it.

Why Teams Outgrow Frameworks

LangChain, CrewAI, and Google ADK are agent frameworks. They give you 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.

Here's what Connic removes from the production backlog around your agent code:

The migration isn't about abandoning your agent logic. It's about moving it into an environment that handles the production concerns you should not need to build from scratch.

What Changes (and What Does Not)

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

Before and After

Here's a concrete example: a LangChain support agent with two tools.

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 your 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 does the heavy lifting:

What Migrates Automatically vs. Manually

Not everything migrates automatically. Here's a realistic breakdown:

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, your project follows a clean, opinionated structure. This is the same structure whether you migrate or start fresh:

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 You Get After Migration

Once your project is migrated, the production concerns are handled for you:

Step-by-Step Migration Checklist

Whether you use the automated CLI or migrate manually, the process looks like this:

• 1.Run the migration: connic migrate --source ./your-project --dest ./connic-project
• 2.Read the migration report. Address every follow-up item in MIGRATION_REPORT.md
• 3.Verify agent configs. Open each YAML file in agents/ and confirm the system prompt, model, and tool references
• 4.Check tool imports. Make sure functions in tools/ have all their dependencies
• 5.Remove framework code. Delete superseded LangSmith integrations, custom runners, and deployment scripts
• 6.Restructure complex patterns. Convert RAG pipelines to retrieval tools, callbacks to middleware, state to sessions
• 7.Develop and test. Run connic lint, iterate with connic dev, and run connic test if the project has a declarative test suite
• 8.Deploy. Run connic deploy or push to your connected Git repository

The Bottom Line

Migrating from LangChain or ADK isn't about rewriting your 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 you start from a converted project instead of a blank one.

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