Are Cursor Rules Deprecated? Legacy Files and Migration

Cursor has evolved its rule file format over time, moving from a single .cursorrules file at the project root toward a .cursor/rules/ directory that holds individual rule files with per-rule configuration. The older format still works in many versions, but it lacks the glob scoping and per-rule settings available in the newer format. Understanding which format your version supports — and how to migrate if needed — lets you take full advantage of current features without breaking rules that still work. fenbs helps teams keep the project decisions behind their rules in one place during a migration, so the reasoning survives the move even when the files change.

The most important check is the Cursor documentation for your current version. Rule file formats can change between releases, and the status of any given format — supported, deprecated, or removed — is determined by Cursor, not by this article. Before migrating, confirm what your version supports.

The original .cursorrules file

The .cursorrules file is a single file at the project root that holds all instructions in plain text. It was the original format and is still recognized by many Cursor versions as a global project rule. Its limitations: all rules apply to all files with no scoping, there is no per-rule configuration, and it does not support the newer markdown-based rule syntax with frontmatter.

If your project uses a .cursorrules file and it still works in your version, you do not need to migrate it immediately. A migration makes sense when you want to scope rules to specific file types, when the file has grown large and unfocused, or when you upgrade to a Cursor version that no longer reads the old format. Check the Cursor changelog before deciding.

The .cursor/rules/ directory format

The current format stores each rule as a separate file inside .cursor/rules/. Each file uses MDC (Markdown Components) format with a YAML frontmatter block that sets the rule's description, glob pattern, and activation mode. This format allows scoped rules, rule libraries, and more precise control over which files receive which instructions.

---
description: TypeScript conventions for the API layer
globs: src/api/**/*.ts
alwaysApply: false
---

Use the Result type from lib/errors.ts for all service return values.
Do not throw exceptions from service functions.
Map Results to HTTP status codes in the controller layer only.

Rule activation modes

The newer format supports different activation modes that determine when a rule loads. An always-on rule loads for every session. A scoped rule loads when a matching file is open. An agent-requested rule is described in the rule listing and loaded when the assistant decides it is relevant. Check the Cursor documentation for the current names of these modes, as they may vary between versions.

The activation mode matters for how you write the rule. An always-on rule should be short and broadly applicable. A scoped rule can be longer and more specific because it only loads when relevant. A rule that would add noise in most sessions is a better fit for a scoped or agent-requested mode.

How to migrate a .cursorrules file

1. Read the current .cursorrules file and list every distinct instruction. Group related instructions by file type or subject.
2. Create a .cursor/rules/ directory if it does not already exist.
3. For each group, create a new .mdc file with a descriptive name. Add the frontmatter with description and glob pattern. Move the relevant instructions into the file body.
4. Test each new rule file by opening a matching file in Cursor and verifying the rule loads in the context panel.
5. Once all rules are migrated and tested, decide whether to keep the old .cursorrules file as a fallback or remove it. If your team uses multiple Cursor versions, keeping it temporarily avoids breaking anyone who has not upgraded.

What to do with rules that no longer apply

Migration is a good opportunity to audit the existing rules. Remove any rule that describes a pattern your project no longer uses, references a library you have replaced, or reflects a convention that changed after a framework upgrade. A wrong rule is worse than no rule, because it misleads every assistant that reads it.

For each rule you remove or change, record why in your team's decisions or lessons. "We removed the Redux rule because the project migrated to Zustand in October 2026" is useful context for anyone who finds the old rule in git history or asks why the instruction is gone.

How to do this with fenbs

1. Create a free account and add a project for the codebase you are migrating.
2. Before migrating rule files, add the existing rules and their reasoning to fenbs Skills and prompts. This creates a snapshot of the current state that survives any file format change.
3. Record the migration decision in Decisions and rules: which format you are moving to, why, and which Cursor version requires it.
4. As you migrate each rule, update the fenbs entry if the rule text changes. Record any rules you removed and why.
5. Connect your AI tools from Integrations so they read the current rules from fenbs at the start of each session, regardless of the local file format.

Staying current with Cursor rule format changes

Cursor is actively developed and rule file formats can change between major versions. Subscribe to the Cursor changelog or check the documentation when upgrading. A format change typically gives you a period of backward compatibility before the older format stops working, which gives you time to migrate without urgency.

The cursor rules hierarchy article covers how different rule scopes interact in the current format. The cursor rules globs article explains how to write the glob patterns used in the frontmatter of the new format.