Hola JoAnCa,
A partir de FB 3 han cambiado muchas cosas en el mundo de Firebird. Por empezar con el tema de seguridad para el acceso a las bases de datos, las tablas de auditorías, y ahora que por lo que he leído en algunas noticias al parecer se incluye replicaciones. Yo admito que estoy un tanto desactualizado en Firebird (me he quedado en la 3) ya que en donde trabajo desde hace años usamos MySQL.
El esquema embebido que tanto se usa en Firebird 1.5 a 2.5 inclusive puede que ya NO exista de manera oficial. Al menos eso parece darme a entender la Documentación en los Release Notes. Yo dejé de usar el enfoque embebido en 2.5 y opté en los trabajos que hice por SuperClassic (que vendría a ser una especie de mix del Classic y SuperServer) y en otras ocasiones de SuperServer. Pero todo dependerá de tus necesidades.
Ahora, no se si funcionará el truquito de copiar la dll de Firebird a la carpeta de tu sistema (que es lo que hacíamos en Firebird anteriores para hacer la versión embebida). Quizá resulte.
Tendrías que consultar en detalle más la documentación oficial para saber si es posible de seguir haciendo versiones embebidas. O en última probar suerte consultando el tema en su mailing-list.
Ahora bien, sugiero que leas las Release Notes y las guías de Migración de versiones anteriores a las nuevas para interiorizarte de los cambios. No son pocos. Yo también debo ponerme al corriente. 
Ahora, por el otro punto. Al parecer hay algunas tools de migración: DBConvert, MySQLToFirebird (aunque parece algo desactualizado y no te garantizo que funcione todo), FullConvert (por lo visto hay opcion trial por algunos días).
Creo recordar que IBSurgeon y/o IBPhoenix tenían cosas para migraciones, pero que eran pagos.
En última, si ninguna opción es viable lo que puedes hacer es un dump de la base de datos de MySQL y luego modificar el .sql manualmente para hacerlo compatible con el SQL y los tipos esperados por Firebird. Deberás tener presente que por defecto mysldump emplea --extended-insert para lo que es el backup de los datos de las tablas. Esto genera una una instrucción INSERT INTO() más compacta, que con 1 un INSERT INTO() es posible de hacer múltiples volcados pasando los registros separados por comas así:
INSERT INTO ... bla bla VALUES (data1), (data2), ... (data3);
Y creo recordar que eso no SQL stándard por lo que sugiero hacer dump en 2 fases, por un lado las estructuras, y por el otro los datos. Si dispones de triggers sugiero hacer en 3: estructuras, datos y luego migrar los triggers al final.
Espero haber dado un poco de ayuda.
Saludos,
