As a data specialist, I would be extremely annoyed if someone wanted to try to make me into an application dev for the bus factor. That is just shortsighted on the part of your management. It is like asking an accountant to train to do HR. I only bring this up because you are likely to face resistance from these people. I also bring it up because they are not unskilled, they have a completely different profession and if you treat them as being unskilled and stupid it will come across in your training which will create problems.

I believe the first step is to identify what things they will most likely need to be able to do and document them in a Wiki. It is unlikely that they will want these people to create things from scratch but to troubleshoot and hold things together until you return or they hire a new application developer. If this is true, then triage what you want to tell them down to the most important things. Make a list of the most common production problems and then create a cheat sheet for each problem on what to do to fix it.

Teach them things like how to interpret error messages and how to find information in whatever logging your system is doing and when to reboot the server and what will be affected if you do so. Teach them your coding standards. Teach them where the code is stored in source control and how to use that (while I think most database work should be in source control, it is not in many places, so they may not know how to use it.) Give them a list of any applicable server names and passwords and ensure they have the appropriate rights to work on those servers.

Find a local contact for a place that has freelance devs available. Make sure your company knows that they can get support from these people if the problem is beyond the skills of the data people. You, the data people and ultimately your management will be happier if there is a fallback plan. The chances that you can turn these people into application developers in a short time is low. The best you can hope for is that they can fix simple problems and they know where everything is and can explain the business to a freelancer for complicated things.

The document everything you can. The goal is that people can find what they need to do the work if you are not there.

I would also suggest that you start a process of code review with these people. In this case, it is not so much to find code problems as to get them familiar with your most recent code and its requirement, your style of coding and your thought processes about your design. Along the way in explaining things to them, you will likely notice some bugs you hadn't noticed.

When you have a common production problem to deal with after you have gone over the most common issues in a training session, have them shadow you and document every step you take. Make sure you make it clear to them that you encourage questions. If they do the documentation, they are going to be more likely to write it in the way that is best for them to understand. Different people have different learning styles and you are basically creating a Wiki that will be more useful to them than you. So let them decide how to organize it.

If their duties keep them from shadowing you, then do the wiki entire yourself as you work on the problems while they are fresh in your mind.

For some simple problems, after they have shadowed you and the steps have been documented, then you have them take the steps while you shadow them. This will give them more confidence that they can actually do the task. This is what we did when we converted some application devs recently to data specialists.

The basic teaching philosophy should be