<…> Also, converting data between systems is not easy.
Migrating the actual information from one system to another should not be that much of an issue, especially since both the current forum and the future-to-be Epochtalk based forum have SQL type databases. Setting-up the same base collation page, and checking the size, datatype, and referential integrity are an essential part of the procedure. The tougher data elements to tackle are likely functionality related fields and values, which need to be guaranteed to exists and interpreted in the same manner on the migrated software (or plan their mapping to different values if required).
Functionality (not data) is the hard-core keystone here, where I figure the specks of Epochtalk have been specified in order to allow the creation of an abstract layer of functionality necessary to implement n-different variant configurations of a forum instance (i.e. Epochtalk could implement Bitcointalk, but many more forums with a common backbone, but different parametrizable/add-on modules/features). On top of that, Epochtalk should guarantee being a functional supraset of Bitcointalk. If Bitcointalk were to constantly evolve, these innovations should form part of Epochtalk specifications (core or modules), thus slowing even more the software development cycle.
That does not mean that Bitcointalk SMF based functionality could/should not evolve, but it is likely deliberately set on hold (except for quick-wins) in order to not slowdown Epochtalk refinement even more.