Q: What is the best way to move a large company to Cucumber with at least 15 years of legacy software requirements maintained in a requirements database?

Currently considering:

1) Migrate Everything

Downside: we don't have unlimited time/budget, we have to move forward to survive, we can't stop everything and GC 100% of our legacy requirements and legacy test suites.

2) Boy Scout Rule

Leave everything better than you found it. If you touch requirements or change them write/update a Cucumber feature. Downside: We will have two systems of record (Cucumber, legacy req. DB), possibly for ever assuming there are corners of a given application that don't get touched for a very long time.

3) Boy Scout Rule Plus

Same as #2 but put requirements which we are not net moving to Cucumber into Features with a single pending scenario and copy/paste the legacy requirements into the description section. This way we get metrics (via pending scenarios) as to how "covered" we are by Cucumber, and also riding us of the need to maintain the old requirements system. I can't find any downsides to this other than it might be a huge mess within Cucumber.

4) Insert your idea here.


Some projects moving to Cucumber have automated test suites, some only ever used manual testing. All of them maintain their requirements in a legacy requirements database. We have to do this because our requirements are a mixture of laws/regulation and complex logic for financial instruments (risk, pricing, structure, etc...).

Keep in mind this is a very large company making the move, which complicates solutions further.

We already have some projects using Cucumber for their "new" requirements. So we have piloted the tech and it's work for us so far. We have a mixture of web and purely data projects.


Edit: To respond to the questions... The legacy requirements management DB does not connect requirements to tests. It's is not "testable". Today connecting requirements to tests is done through an arduous and error prone manual process of linking requirements to our test case management system at the end of each project. Cucumber is an obvious better solution for us. There is no question about that. The question is just how to make the move for a large organization with an immense amount of important requirements that cannot be lost for legal and other reasons.

  • 1
    +1 on the question; but in a more general setting: how to move from one testing system to another? Commented Jan 6, 2016 at 5:55
  • Is the "legacy" requirements database automated in checking the requirements match? Are you going to need to re-word requirements to match Cucumber syntax (and if so: ensure the re-wording doesn't modify the requirements in a subtle way)? Commented Jan 6, 2016 at 5:58
  • Just curiosity, is this database of requirements "testable"? if yes, then you could try to automate the process as a #4 option by doing a program which reads the legacy tests and tries to write a cucumber test for you EVEN if the tests are not in a readable fashion. Having two sources of true is not usually recommended because of missmatches possibles (2 requirements sources, the db and cucumber) Commented Jan 6, 2016 at 12:06
  • 1
    You wrote "we have piloted the tech and it's work for us so far", but you did not wrote "it worked better than the previous tech". So, are you 100% sure this will be an improvement? Otherwise, the best way might be not to do it ;-)
    – Doc Brown
    Commented Jan 6, 2016 at 17:18

1 Answer 1


I made the mistake of stripping a room down to the studs when I replaced its windows. It's an old house. The room was in bad shape. At every step along the way, I ran into issues. An old pipe crumbled in my hand. The now-dangling twenty five pound plumbing vent fell and crashed through the kitchen ceiling. (Luckily, no one was hurt but my girlfriend's charging cell phone was crushed. She was not amused.) I shocked the hell out of myself when I simultaneously brushed against a grounded and ungrounded circuit. There was exposed ancient wiring running through blown-in insulation.

With each issue, I had to redirect my energies. I stopped to fix the problem. Then, sometimes days later, I resumed forward progress. By fall, I gave up. (I planned on being done by late summer.) I just stopped and walked away. It was too much. My girlfriend wanted to call a contractor. I refused since I'd done so much work already. I didn't want them getting the "glory". (Also, I'm a bit particular and didn't want someone cutting corners where I knew I wouldn't.) So, the room sat unfinished.

Almost a year ago, after New Year, I had an epiphany: There was no rule that said I had to work exclusively on the room until it was finished. There was no rush. I didn't have to make it such a big deal. Instead, if I had a little free time, I could go upstairs and spend an hour or two in the room... hang a sheet of Sheetrock, mud and tape a wall, trim up a door. Before I knew it, I was done. My girlfriend loved me again. I slept with a grin on my face. All was right in the world.

I think there's something similar available for your predicament. Be the wise tortoise -- slow and steady. The "Migrate Everything" path is too stressful. It'll make you throw up your hands and walk away. The Boy Scout Rule leaves features behind if they never change. The Boy Scout Rule Plus creates sub-par requirements. Take the best of your approaches:

  1. If you touch a requirement, move it to Cucumber.
  2. In the meantime, set a weekly migration goal. Do a little bit each week. Don't make it an all or nothing proposition. You may find that the occasional migration work is a nice reprieve from all the other work you've committed to.

Before you know it, you'll be done. Your boss will love you. Your team will love you. You'll sleep with a smile on your face.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.