I haven't ever developed directly in dx9, but have previously developed in xna 4.

Currently I am developing in dx11 and find the whole deferred rendering and cbuffer concept simple and logical, I wouldn't ever want to go back to the old ways.

DirectX 11 and above are the future but on that note your dx9 apps will still continue to work for quite some time.

Good luck in your decision!

Back on-topic, and regarding differences between the two, there are a few areas where (even if you're currently exclusively using vertex buffers and shaders) you may find it difficult.

If you're extensively using D3DX you'll either have to rewrite or find replacement libraries.

If you're using the Effects framework you're strongly advised to switch over to the base API. Effects 11 was distributed (as source only) with the old DirectX SDKs, but it's far from being the most efficient option.

DXGI is hugely different from the old D3D9 way of doing things. You've basically two options here: let DXGI handle everything automatically but at the cost of losing some flexibility (which may be important to you), or disable the automatic handling and have to deal with all of the low-level nitty-gritty of window management yourself. Neither is perfect but that's just the way it is.

States are also very different and you'll be creating state objects up-front rather than issuing Set*State calls as required and based on what you're drawing and how you want to draw it. This needs a lot more advance planning than D3D9 did, especially if you've built up a reasonably flexible renderer where you don't necessarily know everything up-front.

If D3D9 is currently doing everything you need, if you're not currently hitting any of it's limitations, and if you've no compelling reason to use any of the new API features, I'd suggest that you stay with 9 and invest your time and effort into improving your D3D9 renderer. Otherwise you could find yourself this time next year with no progress made aside from a port to a new API.

If you do decide to make the jump then I'd suggest that you begin by staying with 9 initially but rewrite where necessary to tackle the areas where you're going to hit trouble. So remove your usage of D3DX, move away from Effects to the base API in 9 (use D3DCompile for compiling shaders), move away from Set*State calls to StateBlocks, and create StateBlocks that encapsulate the same groups of states that D3D11 state objects do. That way it'll go a lot easier on you when you come to do the port for real.

Might want to hold off a bit if it isn't a major issue yet; DX12 will bring another major API shift and with Win10 going 'free' for anyone with Win7 or Win8 it could well get a lot of traction.

For very experienced developers, hobby or otherwise, I think this advice rings true. But I'm no so sure for less-experienced devs, or those who don't care about ultimate performance at the cost of dealing with the much-more explicit model of D3D12. I think ultimately there will end up being an "easy mode" API that puts the training wheels back on Direct3D 12 for those who want a simpler model and don't need unfettered performance, but as far as I've heard, no such thing is coming immediately, and Direct3D11.x will sort of serve that role in the meantime.

And as Hodgeman suggests, the best thing to probably do now is to use D3D11 in a way that prefers the constructs and patterns that'll stick around in the new world order.

That said, there's probably a balance to be struck, too -- We all know the hoops one must jump through in old-world Direct3D to make a scene look good in only a few thousand draw calls (and etc.), and I think there's a case yet to be made whether dealing with the newly-explicit threading models and synchronization issues (+more)of D3D12 are a greater or lesser headache than that in the long run. But at least for the immediate term D3D11 (and 9, even, if you want to target Asia) makes a lot of sense until everyone is on Windows 10, and that will give more-experienced, early-adopters of Direct3D 12 time to figure out what best-practices are for the less-experienced to follow.