From VS Code to Neovim in 30 Days, A Senior Dev's Migration Plan

TL;DR — Week 1, motion and editing only, no plugins. Week 2, LSP, completion, navigation. Week 3, real work with the editor as primary. Week 4, tmux, debugging, and the polish that makes it stick. Plan for a 20-30% productivity dip in weeks 1-2 and full recovery by week 4.

People ask me how long the VS Code to Neovim switch takes. The honest answer is “about a month to be productive, six months to be faster.” The 30-day part is non-negotiable, you can’t speedrun building Vim motions into your hands. The six-month part is where you stop thinking about the editor and start thinking about the code.

This post is the plan I wish I’d had. It’s structured around what to learn each week, what to ignore, and what to expect from your output curve. I’ve helped four colleagues through this transition with roughly this schedule, and it works.

A note on prerequisites. You should be comfortable enough in VS Code that you’re not still learning your existing tools. Switching editors while you’re still figuring out git is too much change at once. Wait until your current setup is on autopilot, then start this.

Week 1, Vim Motions Only

The first week, no plugins. Open Neovim with a minimal init.lua and learn motion.

-- Minimal week-1 init.lua
vim.opt.number         = true
vim.opt.relativenumber = true
vim.opt.expandtab      = true
vim.opt.tabstop        = 2
vim.opt.shiftwidth     = 2
vim.opt.ignorecase     = true
vim.opt.smartcase      = true
vim.g.mapleader        = ' '

Spend an hour with :Tutor on day one. Then use Neovim for personal coding only, side projects, scratch scripts, anything where slow output won’t impact your team. Keep VS Code open for work.

The goals for week 1 are narrow.

• h/j/k/l instead of arrow keys, no exceptions
• Word motion (w, b, e)
• Line motion (0, ^, $, gg, G)
• Find character (f, t, ;, ,)
• Basic edits (i, a, o, O, x, r)
• Operators (d, c, y, p) combined with motions
• Text objects (iw, aw, i", a", i(, a()
• Undo/redo (u, <C-r>)
• Save, quit (:w, :q, :wq)

That’s it. No splits, no buffers, no plugins. Just motion and editing.

The reason for the constraint is muscle memory. If you skip ahead to LSP and completion, you’ll lean on those features and your motion practice will be shallow. Six months later you’ll still be hunting for keys.

By the end of week 1, you should be able to navigate a 200-line file without arrow keys or mouse. You’ll be slow. That’s fine.

Week 2, LSP and Completion

Now you add the plugins. Drop in lazy.nvim, nvim-lspconfig, mason.nvim, and nvim-cmp. I covered the exact config in Bootstrapping Neovim with lazy.nvim and Mason, use that as the starting point.

Install language servers for whatever you actually work in. Don’t install a server “in case I write Rust someday.” Just the ones you’ll use this week.

-- Week 2 additions to plugin specs
require('mason-lspconfig').setup({
  ensure_installed = { 'gopls', 'pyright', 'tsserver' },  -- yours will differ
})

-- The four LSP keymaps that matter most this week
local map = vim.keymap.set
map('n', 'gd',        vim.lsp.buf.definition)
map('n', 'gr',        vim.lsp.buf.references)
map('n', 'K',         vim.lsp.buf.hover)
map('n', '<leader>rn', vim.lsp.buf.rename)

Goals for week 2.

• Go-to-definition (gd) and back (<C-o>)
• Find references (gr)
• Hover documentation (K)
• Rename symbol (<leader>rn)
• Completion menu navigation (<C-n>, <C-p>, <CR> to accept)
• Diagnostic navigation (]d, [d)
• Basic splits (<C-w>s, <C-w>v, <C-w>h/j/k/l)
• Buffer switching (:bn, :bp, or telescope’s buffers picker)

Still keep VS Code as your primary work tool. Use Neovim for personal projects and read-only browsing of work code. The goal is that by the end of week 2, you can read code in Neovim as fast as in VS Code.

The temptation here is to install 30 plugins and customize colorschemes for three hours. Resist. Add what you’ve named above, nothing else.

Week 3, Make Neovim Primary

Week 3 is the hardest. You switch to Neovim as your daily driver for actual work. Output will drop. Plan for this with your team if possible (avoid scheduling a release week for this), or do it through a quieter sprint.

Add navigation and quality-of-life plugins.

-- Week 3 additions: telescope, treesitter, statusline, file management
{ 'nvim-telescope/telescope.nvim',
  dependencies = { 'nvim-lua/plenary.nvim',
                   { 'nvim-telescope/telescope-fzf-native.nvim', build = 'make' } },
  keys = {
    { '<leader>ff', '<cmd>Telescope find_files<cr>' },
    { '<leader>fg', '<cmd>Telescope live_grep<cr>'  },
    { '<leader>fb', '<cmd>Telescope buffers<cr>'    },
  } },

{ 'nvim-treesitter/nvim-treesitter',
  build = ':TSUpdate',
  opts  = { highlight = { enable = true }, indent = { enable = true } } },

{ 'stevearc/oil.nvim',
  cmd  = 'Oil',
  keys = { { '-', '<cmd>Oil<cr>' } },
  opts = {} },

Goals for week 3.

• Telescope for file finding and grep (<leader>ff, <leader>fg)
• Quickfix list for project-wide changes (:cdo, :cn, :cp)
• Macros (q<letter> to record, @<letter> to play, @@ to repeat)
• Marks (m<letter> to set, '<letter> to jump)
• Registers ("<letter>y, "<letter>p)
• File management with oil or netrw

Expect a productivity dip of 20-30% this week. That’s normal. You’re rewiring habits and the muscle memory hasn’t fully transferred. The dip recovers, fast, if you don’t give up and switch back to VS Code.

The single rule for week 3, do not open VS Code for work. If you find yourself reaching for it, fix the gap in your Neovim setup instead. Almost always the gap is “I don’t know the keybinding,” not “Neovim can’t do this.”

Week 4, Tooling and Polish

By week 4, you should be reasonably productive in Neovim. Output is back to roughly 90% of pre-switch. Now you add the layers that compound over time.

-- Week 4 additions: tmux navigation, DAP for debugging, AI assist
{ 'christoomey/vim-tmux-navigator',
  keys = {
    { '<C-h>', '<cmd>TmuxNavigateLeft<cr>'  },
    { '<C-j>', '<cmd>TmuxNavigateDown<cr>'  },
    { '<C-k>', '<cmd>TmuxNavigateUp<cr>'    },
    { '<C-l>', '<cmd>TmuxNavigateRight<cr>' },
  } },

{ 'mfussenegger/nvim-dap',
  dependencies = { 'rcarriga/nvim-dap-ui', 'nvim-neotest/nvim-nio' } },

{ 'zbirenbaum/copilot.lua',
  event = 'InsertEnter',
  opts  = { suggestion = { auto_trigger = true } } },

Goals for week 4.

• tmux for session persistence and project scoping
• nvim-dap for debugging (use it on a real bug, not just to play)
• Inline completion (Copilot or Codeium)
• Treesitter text objects (af, if, aa, ia)
• Your own snippets, written by hand for the patterns you actually type often
• One or two genuinely customized keybindings, the ones you find yourself wishing existed

By end of week 4, you should be at 95-100% of your pre-switch output. The remaining 5% comes back over the next 2-3 months as motion becomes truly reflexive.

The Failure Mode

The most common failure is the bargain-with-yourself trap. “I’ll use Neovim for some things and VS Code for others.” It doesn’t work. The two editors have different motion grammars. Splitting your time between them means neither set of habits hardens, and after three months you’re still slow in both.

Either commit fully or don’t switch. Commit means VS Code closed, period, for the duration of the 30 days. After that, you can use whatever you want for whatever reason, but during the migration window the editor is binary.

The second failure mode is over-customizing in week 2. People discover Lua and spend a Saturday writing a fancy statusline. Don’t. Customization is the reward for getting productive, not the path to getting productive.

Common Pitfalls

A few traps specific to this migration.

• Copying someone’s full config. You won’t understand what each plugin does, so when something breaks you can’t fix it. Build yours up from scratch following this plan.
• Skipping :Tutor. It’s 30 minutes. It teaches you things you’d otherwise discover painfully over weeks.
• Mapping jk to <Esc>. It’s tempting and you can do it, but Caps Lock to Escape at the OS level is better, it works in every program, not just Neovim.
• Treating the file tree like VS Code’s sidebar. Use a fuzzy finder for most navigation; treat the file tree (oil, neo-tree) as a tool for understanding structure, not opening files.
• Reaching for the mouse out of habit. When you catch yourself, force yourself to find the keyboard equivalent. Every time you give in, the habit weakens.
• Quitting before week 3 ends. The dip is real and the temptation to “just use VS Code for this one urgent thing” is strong. Push through. Week 4 you’ll be glad you did.

Wrapping Up

30 days is enough to be productive. Six months is enough to be faster than you were before. The investment is real and the payoff is real, but the trick is structuring the transition so you don’t burn out in week 1 or stall in week 3.

The plan above is what worked for me and for the colleagues I’ve helped through it. Adjust the language servers and plugin choices for your stack, but keep the weekly progression. Motion first, LSP second, navigation third, polish fourth.

The official Neovim documentation is the canonical reference, and the Neovim community wiki lists resources by language and use case if you get stuck. Worth bookmarking before you start.

Don’t rush. Don’t bargain. Don’t open VS Code for 30 days. That’s the whole plan.