In your case I don't think BDD (or its cousin TDD) is necessarily the right tool for what you are doing.
Rather than developing application code based on desired behavior as captured in tests, it sound like you already have the application code and want to address the technical debt of not having test coverage for it, i.e. technical debt - missing tests.
So I would consider 'dropping down a level' and using a test framework at a lower level. For .NET this would be NUnit. I believe this would let you move a lot faster, with less overhead, to gain that coverage that you desire.
The tough part here is, as you move from tackling debt to testing new changes as they are made, you may want to use BDD and TDD techniques. Personally I still say wait until then to start writing them. Find ways to leverage what you are have already written in NUnit at that point. After all you'll have made a good step for 'documentation as code' with them so it should be much easier to do that, compared to the manual setup you have now.