Some time ago I posted about the risk you face in creating a database that becomes essential for your group's daily operations. By no means should you think of NOT creating or pursuing the database. It is a double-edged sword: creating an innovative and useful database will increase your value and the success of your group, while it can also add to your workload and cause your management a bit of fear when they think of promoting you or your departure.
Step 1: Set Expectations
Set clear expectations with your management about what your Access database can do functionally, and what it can do with and without you. It may continue to work perfectly even if you are gone for weeks. Or it might need daily care and feeding. Either way, make sure you've communicated what it takes for your database to keep working, and what skill level is needed if you are gone. Ideally your manager will be an ally, and make certain to facilitate finding a prospective replacement. It also helps them to understand how much hard work you've put in to saving your group time and money.
Step 2: Find a Replacement
Look for someone in your group to begin sharing the work with. If your application has been visible to others in your group, you may have no trouble finding someone willing to start taking some of the "hero" spotlight. And you don't need to tell them you're hoping for a promotion, just that you'd like someone to help cover questions and issues if you're out of town, on vacation, or sick.
It's likely that no-one will have your level of expertise in Access. If so, you can try to convince your manager to fund an online Access class, or a book or two to help cross-train your colleague.
Step 3: The Transition
I've been fortunate to move to new positions several times in my career. At least three included a departmental Access database that needed someone to take care of when I moved on. Try setting up a series of short meetings to transition your responsibility. Breaking your transition into several sessions gives some breathing time for you to remember details you might want to pass on, and the new person can assemble questions and absorb the information for the next session. You may be tempted to apologize for poor code quality, imperfect architecture, and ineffecient steps. Rest assured the person you are transitioning to will likely not recognize these facts, and will have an opportunity to improve upon them in due course (if they have the interest!).
