Capisco che a volte si è costretti a stare nella 'preistoria', d'altra parte però occorre prendere atto che non sempre è possibile utilizzare componenti preistorici ed allo stesso tempo pretendere di usarli nei nuovi sistemi operativi.
Avere la botte piena e la moglie ubriaca non è sempre possibile.

Vediamo se si riesce ad aggiornare quel tanto da poter eseguire il programma anche in Windows 8.x.

Prima di tutto devi aggiornare le tue informazioni (anche per il futuro) leggendo questo documento:
Support Statement for Visual Basic 6.0 on Windows Vista, Windows Server 2008, Windows 7, Windows 8 and Windows 8.1, Windows Server 2012, and Windows 10
https://msdn.microsoft.com/en-us/vstudio/ms788708.aspx

Vedrai che il Jet35 non è più supportato.

DAO?
Forse (non uso DAO per cui le mie indicazioni potrebbero non corrispondere a verità) per continuare ad usare DAO dovresti aggiornare il tuo programma al Jet36.
In tal caso, se ti è possibile, migrerei da Access97 a Access2000 o meglio ancora Access2002.

ADO?
Se pensi di migrare ad ADO (raccomandato) le cose sono un po' diverse, dato che DAO e ADO sono completamente differenti.
Solo il nome degli oggetti sono simili, ma il loro utilizzo e le loro potenzialità sono totalmente diverse.
In DAO hai un set completo per manipolare le strutture degli oggetti specifici di Access (Tabelle, Campi,..) cosa che ADO non ha, essendo pensato NON per Access ma per un uso più universale.
Per ADO si usa ADOX:
Microsoft Access tips: ADO Programming Code Examples
http://allenbrowne.com/func-adox.html

Con ADO puoi accedere a qualsiasi database, inclusi quelli di Access 2007 in poi (*.accdb)

Il vantaggio di usare ADO è che la versione 2.8 è già pre-installata in tutte le versioni di Windows (la v2.5 già da Windows 2000) così non devi preoccuparti di distribuire nulla.
Al contrario con DAO è più complicato: se, da come sembra, distribuisci il programma a terzi, nel tuo setup devi allegare l'installazione di DAO in tutte le versioni possibili.
Infatti ne esistono una per ogni versione di Windows che oltre a questo deve essere anche localizzata nella lingua del sistema operativo.
Non è finita: devi anche istruire il tuo installer ad installare quella corretta a seconda dell'ambiente che trova.
Naturalmente il tuo installer dovrà essere in grado di consentire di allegare i vari pacchetti di setup distribuiti da Microsoft fatti apposta, individuare l'ambiente sottostante e consentirti di parametrizzare quale setup usare.

La migrazione da DAO ad ADO non è difficile ma può essere articolata, tenendo conto delle varie differenze nell'uso degli oggetti ADODB, e soprattutto nei caratteri jolly diversi utilizzati dai due nelle query.

Comunque, prima di ogni cosa, è assolutamente indispensabile fare dei test su macchine virtuali (delle varie versioni di Windows) per vedere sia come funziona il programma, sia come funziona il setup (che deve essere perfetto).
Personalmente ho due macchine virtuali per ogni versione di Windows:
- una pulita che uso per testare l'installazione e l'esecuzione del programma
- una con l'IDE che uso per lo sviluppo e debug del programma, solo nei casi in cui lo stesso si comporti diversamente in quell'ambiente operativo.