There isn't as much to be gained from this as most people seem to think, and this is most likely why the effort in development is piecemeal.  So at some point we will have done enough to complete the task, but for now I can't provide you with a date, can only say it's a work in progress.

This doesn't mean there is nothing to be gained of course, only that most people seem to think this is the answer to all performance issues etc.  It isn't.  The biggest improvements will actually come from fixing other things in Studio and these optimisations can be obtained while on 32-bit.  We are already starting to move certain processing tasks outside of the Studio main processes so that we can have a more performant application.

Thanks, Paul, for your reply. It's good to know that this needed update is in progress. Let me quote Microsoft about using 64-bit Windows applications: "[...] 64-bit applications can access more memory than 32-bit applications (up to 18.4 million Petabytes). Therefore, if your scenarios include large files and/or working with large data sets and your computer is running 64-bit version of Windows, 64-bit is the right choice [...]" https://support.office.com/en-us/article/Choose-between-the-64-bit-or-32-bit-version-of-Office-2dee7807-8f95-4d0c-b5fe-6c6f49b8d261 In other words, we, SDL users, will take advantage of accessing and using more efficiently bigger amounts of computer memory and faster performance, in general, particularly when it comes to huge translations jobs, huge sdlxliff files, TMs, termbases, etc.  

A related issue is the 64-bit Office version, since SDL Studio and Office are intertwined in terms of the underlying technology, namely Microsoft programming models and technologies. Among the SDL tools to be benefited will be SDL MultiTerm, an application that relies, I presume, on 32-bit COM add-ins (earlier Office integration solutions, legacy code ca. 2000) where the 64-bit alternative will have to be programmed using a more recent and better technology. (Incidentally, I cannot offer a 64-bit version of my SDL appstore application (Tb-Scout for MultiTerm) because there are no 64-bit versions of the corresponding COM add-ins, are they?).

In addition (and this is a suggestion) MultiTerm, could have two versions: one that relies on Microsoft Access, as it is now, (which is constrained, theoretically, to termbases of a maximum size of 2GB) and one that relies on Microsoft SQL Server that allows bigger termbases sizes and way better performance. The free SQL Server Express, which allows databases with 10GB in size will be good enough for a huge termbase, could also be part of MultiTerm Desktop.

Unknown said:

In other words, we, SDL users, will take advantage of accessing and using more efficiently bigger amounts of computer memory and faster performance, in general, particularly when it comes to huge translations jobs, huge sdlxliff files, TMs, termbases, etc.  

Indeed... but as I said Ozzie, if we don't fix more underlying processes first 64-bit would be a huge disappointment.