It sounds like your focus is to write one set of code (with the same language, or the same platform, such as .NET, so that the language of choice of C# or VB.NET would not be an issue) for specific process/functionality, and use them in different applications (in your case, AutoCAD and various MS Office Apps, Access, mainly).
It also sounds to me, that you use MS Access not only as data source, but also as a user application (thus VBA code in MS Access), that is the reason you want to write code that can be shared by both AutoCAD and MC Access. However, you did not provide more details on what kind of "the same thing/process" that would be done in both AutoCAD and MS Access? The example scenario you described on "wireno", "sigcode" can all be handled on AutoCAD side. But I assume in your workflow, the data used by AutoCAD would be manipulated both inside AutoCAD and outside AutoCAD by other app (MS Access's UI, for now).
Based on these scenario, let's see what you can do:
1. AutoCAD side: you can write .NET DLLs that can be shared with any other apps, as long as the DLLs do not have references to AutoCAD .NET API assemblies. For example, you build .NET DLL that only handles data access from external data source (doing the usual CRUD work). Then this DLL can be shared with other apps, be that apps are 64-bit or 32-bit. Ideally, you would create a set of data access interfaces, and implement the interfaces differently against different types of data source, be it MS Access, SQL Server, or web services... (if you know what I am talking).
2. Other Apps that may share the same DLL that is used in AutoCAD. It is unfortunate that MS Access as front application, the UI part, does not support .NET Add-in as other MS Office (Word/Excel). So, you cannot directly share the .NET DLL. You must expose the .NET DLL as COM interop, then you can use the COM interop with MS Access VBA code. While this still makes AutoCAD and your MS Access app share the same DLL, making .NET DLL COM-able adds quite some complexity to the solution and complicates the app's installation/update process a lot. IMO, using MS Access as front UI is bad choice (more likely due to historical reason), if the MS Access is both front UI and database itself, then it is even worse case (MS Access UI should be separated from MS Access database).
If it is indeed that the data need to be manipulated from both inside AutoCAD and outside AutoCAD, then the ideal situation as I can see is to create a .NET stand-alone app (desktop, or web). Then you can have completely share-able DLL(s) that handle data access, ideally through interfaces. In this way, both AutoCAD and the external app can have access to any kind of external data source with very little configuration changes.
Again, if you limit the external app with MS Access, be it by choice, or by historical reason, thing does not look good and the options are limited (COM-able .NET DLLs). If possible, I'd leave MS Access behind (both as front UI and data source) and move on to other better choices. Otherwise, you would struggle with the same issue every time new requirements for updating come up.