Open the monolith project

Architecture rules:

• Each service gets its own Django project with isolated models
• Cross-service communication uses REST APIs only, never direct imports
• Shared data is accessed through API clients, not ORM queries
• Use Django REST Framework for all service APIs
• Database-per-service pattern: each service owns its tables
• Event publishing via Redis Streams for async workflows

Code conventions:

AFTER: Decoupled references in orders-service/orders/models.py

class OrderResponse(BaseModel): id: str customer_id: str status: str total_amount: float created_at: str

class OrderServiceClient: def init(self): self.base_url = os.getenv(‘ORDERS_SERVICE_URL’, ‘http://localhost:8001’) self.client = httpx.Client(timeout=10.0)

def get_order(self, order_id: str, token: str) -> Optional[OrderResponse]:
    response = self.client.get(
        f"{self.base_url}/api/orders/{order_id}/",
        headers={"Authorization": f"Bearer {token}"}
    )
    if response.status_code == 200:
        return OrderResponse(**response.json())
    return None

def list_customer_orders(self, customer_id: str, token: str) -> list[OrderResponse]:
    response = self.client.get(
        f"{self.base_url}/api/orders/",
        params={"customer_id": customer_id},
        headers={"Authorization": f"Bearer {token}"}
    )
    response.raise_for_status()
    return [OrderResponse(**item) for item in response.json()["results"]]</code></pre>

Week 3: Database Separation and Data Migration Scripts

Cursor's codebase awareness proved critical here. When generating migration scripts, it understood which tables belonged to which service because it had already analyzed the full model dependency graph: # docker-compose.yml for isolated databases services: db-auth: image: postgres:16 environment: POSTGRES_DB: auth_service POSTGRES_PASSWORD: ${DB_AUTH_PASSWORD} ports: - "5432:5432"

db-orders: image: postgres:16 environment: POSTGRES_DB: orders_service POSTGRES_PASSWORD: ${DB_ORDERS_PASSWORD} ports: - “5433:5432”

redis: image: redis:7-alpine ports: - “6379:6379”

Week 4: Integration Testing and Event Bus Wiring

The final week focused on replacing synchronous cross-service calls with event-driven patterns where appropriate. Using Cursor Chat with the full project context: # events/publisher.py import redis import json from datetime import datetime

class EventPublisher: def init(self): self.redis = redis.Redis( host=os.getenv(‘REDIS_HOST’, ‘localhost’), port=6379, decode_responses=True )

def publish(self, stream: str, event_type: str, payload: dict):
    self.redis.xadd(stream, {
        'event_type': event_type,
        'payload': json.dumps(payload),
        'timestamp': datetime.utcnow().isoformat()
    })

publisher.publish(‘orders’, ‘order.created’, { ‘order_id’: str(order.id), ‘customer_id’: str(order.customer_id), ‘items’: [{‘sku’: i.sku, ‘qty’: i.quantity} for i in order.items.all()] })

Results: Quantified Impact

Cursor Indexing Stalls on Large Projects

If indexing does not complete, exclude unnecessary directories. Add to .cursorignore: # .cursorignore node_modules/ .venv/ *.pyc __pycache__/ media/ static/collected/ ### AI Generates Direct Imports Instead of API Calls

This happens when the context window lacks your architecture rules. Ensure .cursorrules is in the project root and restart the Composer session. Explicitly reference the rule: *"Remember, cross-service communication must use REST API clients, not direct imports."*

Composer Loses Track of Changes Across Many Files

When editing more than eight to ten files simultaneously, Composer can produce inconsistent results. Break the task into smaller batches of three to five related files per session. Use git diffs to verify consistency between batches: git diff —stat HEAD git diff —name-only | grep “orders/“

Circular Import Errors After Refactoring

If you encounter ImportError: cannot import name X from partially initialized module, the AI likely left a stale import. Use Cursor's search to find all references: Ctrl+Shift+F and search for the old import path, then replace with the new service client call. ## Frequently Asked Questions

Can Cursor handle refactoring projects larger than 50,000 lines?

Yes. Cursor’s codebase indexing supports projects well beyond 100,000 lines. The key is using .cursorignore to exclude non-essential files (vendor code, generated assets, binary files) so the index focuses on your source code. For very large codebases, work in focused Composer sessions scoped to specific directories or modules rather than prompting across the entire project at once.

Is AI-generated refactored code production-ready without manual review?

No. Cursor accelerates the mechanical work of refactoring—generating boilerplate, rewriting imports, scaffolding API layers—but every change requires human review. In this case study, approximately 60 percent of AI-generated code was accepted as-is, 30 percent needed minor adjustments, and 10 percent was rewritten manually. The inline diff review workflow is essential: always inspect each change before accepting it.

How does Cursor compare to using ChatGPT or Copilot for large-scale migrations?

The critical difference is codebase awareness. ChatGPT operates on pasted snippets without project context. GitHub Copilot offers single-file autocomplete. Cursor indexes your entire repository and allows multi-file editing in Composer, meaning it understands how a model change in one file affects serializers, views, URLs, and tests across the project. For migrations involving coordinated changes across dozens of files, this context-aware approach eliminates the manual copy-paste workflow that makes ChatGPT impractical at scale.