How to Migrate From Cursor to Amazon Q Developer Without Losing Context (2026)

Start with what each tool documents, because the gap is not where most people expect.

Cursor's rules documentation is explicit about what rules are for and why they exist:

"Large language models don't retain memory between completions. Rules provide persistent, reusable context at the prompt level."

Rules are injected as context: "When applied, rule contents are included at the start of the model context." Each project rule is an .mdc file with frontmatter, and the frontmatter fields determine one of four application types — Always Apply, Apply Intelligently ("When Agent decides it's relevant based on description"), Apply to Specific Files via a glob pattern, and Apply Manually through an @-mention. Cursor also documents a precedence chain: "Rules are applied in this order: Team Rules → Project Rules → User Rules. All applicable rules are merged; earlier sources take precedence when guidance conflicts."

Amazon Q Developer's project rules live in a folder and are plain Markdown:

"Project rules are defined in Markdown files in the project's {{project-root}}/.amazonq/rules folder."

And they are applied without a declared condition:

"Once you've created your project rules, Amazon Q will automatically use them as context whenever a developer chats with Amazon Q within your project, and will make sure to adhere to them when generating answers."

The control surface is the Rules button in the chat panel, which lists your rules and lets you toggle each one for the current session: "Rules with a check mark are active and will be applied to your conversation." The same .amazonq/rules folder is documented for Amazon Q Developer in GitLab and GitHub, so the layer is not IDE-only.

So the transfer looks like this. Rule content transfers cleanly — it is prose in a Markdown file on both sides. Rule conditionality does not. Cursor's four application types collapse into one documented behavior plus a per-session checkbox. Nothing in Amazon Q's project rules documentation describes a frontmatter field for glob matching, description-based retrieval, or manual @-invocation.

There is a second thing that does not transfer, and it is the one worth planning around. Amazon Q has its own generated context layer, and it lands inside the same folder you are about to migrate into.

Two steps. The first is mechanical and the second is the one people skip.

Step 1: Strip the frontmatter and fold the condition into the prose

Cursor is strict about the file extension: "Each rule is an .mdc file that you can name anything you want. Project rules must use the .mdc extension. A plain .md file in .cursor/rules is ignored by the rules system because it has no frontmatter to specify description, globs, and alwaysApply."

Amazon Q is equally clear in the other direction — the rule file "must be a Markdown file" in .amazonq/rules, and the documentation shows plain prose with no frontmatter.

The literal-value trap is right here. If you copy .cursor/rules/api.mdc to .amazonq/rules/api.md unchanged, you carry three lines of YAML — description, globs, alwaysApply — into a file whose reader has no documented use for them. Amazon Q will not complain. It will treat the frontmatter as part of the rule text, and the conditionality those fields expressed simply stops existing.

So do this instead, rule by rule:

For a rule that was Always Apply, delete the frontmatter and move on. This one is a clean port; it was unconditional in Cursor and it is unconditional in Amazon Q.

For a rule that was Apply to Specific Files, delete the frontmatter and write the scope into the first sentence of the rule itself. A rule whose glob was **/*.test.ts becomes a rule that opens with a sentence naming test files as its subject. You are converting a machine-enforced condition into a stated one, and it is worth being honest that this is a downgrade in precision — the model now decides relevance from your wording rather than from a matched path.

For a rule that was Apply Intelligently, the description field was the retrieval signal. Fold it into the opening line, because it now has to do its work as ordinary prose rather than as metadata.

For a rule that was Apply Manually, decide whether you actually want it always on. Some of these exist precisely because they should not fire by default. Those are the candidates to leave out of .amazonq/rules entirely and keep somewhere you can invoke deliberately.

Cursor's own authoring advice survives the move and is worth carrying with you: keep rules under 500 lines, and "Reference files instead of copying their contents—this keeps rules short and prevents them from becoming stale as code changes."

If you have done a rules translation before, the shape will be familiar — moving Cursor rules to a Codex AGENTS.md hits the same frontmatter question with a different destination format.

Step 2: Keep your authored rules out of the regeneration path

Amazon Q can generate a memory bank for a project, and this is where the migration gets a sharp edge:

"Amazon Q can automatically generate memory bank files that provide a quick index of your project's structure, technology stack, and product information. This feature analyzes key files in your project to create summary files that help Amazon Q understand your codebase without having to analyze the entire project each time you ask a question."

Four files are produced — product.md, structure.md, tech.md, and guidelines.md — and they are written to a memory-bank subfolder under .amazonq/rules. That is the same folder tree you just migrated your Cursor rules into.

The update path is not an edit. It is a rebuild:

"If your project changes, you can have Amazon Q generate new memory bank files to update its context. To do so, choose the Rules button and then select Regenerate Memory Bank."

Two consequences follow. First, anything a teammate hand-writes inside memory-bank/ is sitting in the path of the next regeneration. Second, and more important: because those four files are produced by analyzing your code, they can only ever contain what your code already says. The reason you kept a rule saying "do not use the other HTTP client" is not in the code — the other client is not there. Regeneration cannot produce that sentence, and it never will.

This is worth contrasting with the other well-known memory bank in this space. Cline's Memory Bank is a set of files the agent is instructed to read and update as work proceeds, so its content is whatever the agent recorded about the project's state. Amazon Q's memory bank has the same name and the opposite source: it is generated from the repository. Neither is better; they are answers to different questions, and assuming one behaves like the other is how teams lose content.

So keep the two layers physically separate. Your migrated rules go directly in .amazonq/rules/ as individual files. Let the memory-bank subfolder be generated and treat it as derived output. If you want to shape what generation produces, Amazon Q documents the supported way to do it — a rule in .amazonq/rules that describes the format you want, which is a nice property: the generated layer is steered by the authored layer, not the other way round.

Everything above is a translation job, and you will do it again the next time you change tools. The part that keeps costing you is not the file format — it is that the reasoning behind each rule was never stored anywhere except inside a tool-specific file.

MemoryLake gives that reasoning a home outside both products and serves it to whichever agent asks, over MCP or the API. Cursor keeps its rules and Amazon Q keeps its memory bank exactly as they are; this sits alongside them and holds the layer neither one is designed to store — what you decided, what you rejected, and why.

Step 1: Create an API key

Generate a key and make your first request in about thirty seconds. Do this before you start rewriting rule files, so you have somewhere to put the reasoning as you go.

Step 2: Upload your first memories

As you work through each .mdc file in Step 1 above, you will find yourself reconstructing why the rule exists. Capture that as you go: the convention, the alternative you rejected, and the incident or constraint behind it. Drop in the supporting documents, diagrams, and files too.

Step 3: Connect your AI & agents

Give Claude, Codex, OpenClaw, and Amazon Q access over MCP or the API. An agent that can query the decision layer answers "why is this the convention here" with the reason attached, instead of restating the rule back to you.

The immediate change is that the conditionality you lost in Step 1 stops mattering as much. A glob-scoped rule existed partly to keep irrelevant guidance out of the context window. When the reasoning lives in a store the agent queries on demand, .amazonq/rules can stay genuinely short — the standing commands only — and the long tail is retrieved when it is relevant rather than loaded because it might be.

The second change shows up at the first Regenerate Memory Bank. You will not lose anything, because the things worth keeping were never in the generated files.

The third is that a partial migration stops being a problem. Plenty of teams run Cursor and Amazon Q side by side for months, on different repositories or different halves of a team. Two rule folders in two formats will drift. One decision layer that both agents read does not.

The fourth arrives at the next migration. The rule files get translated again. The reasoning does not, because it was never in a rule file.

Migrate one rule at a time, and read each one. A batch copy is the failure mode here, because it preserves frontmatter that means nothing on the far side and silently discards conditions that meant everything.

Never hand-author inside memory-bank/. It is generated output. Put your files directly in .amazonq/rules/.

Say the scope out loud in rules that used to have globs. Open the rule with the files or directories it applies to. You have converted an enforced condition into a stated one; make the statement unmissable.

Use a rule to shape generation. Amazon Q supports customizing memory bank output through a project rule. That is the documented seam between the authored and generated layers — use it rather than editing generated files.

Do not assume pinning covers you. Context pinning is documented as available only in the VS Code IDE, and pinned items apply to the current chat tab only — a new tab starts fresh. It is a per-conversation convenience, not a durable project layer.

Write down why, once, somewhere neither tool owns. This is the only part of the work that does not repeat.

The Cursor to Amazon Q Developer migration is easy to underestimate because both sides use Markdown in a project folder. The content ports. The conditionality does not: Cursor's four documented application types have no documented counterparts in Amazon Q's project rules, and the four fields in your .mdc frontmatter become inert text if you copy them across.

The second thing to get right is folder discipline. Amazon Q's memory bank is generated into a subfolder of the same .amazonq/rules tree, and it is rebuilt rather than edited. It is a genuinely useful index of what your codebase contains — and for exactly that reason it cannot hold the decisions your codebase does not contain.

Do the translation carefully, keep authored and generated content in separate places, and put the reasoning somewhere that survives the next tool change. Then this is the last time you do this particular translation from scratch.