If you want your existing module or any new module to work on Platform 2.0 and any older version, you need to be aware of the requirement to use DbSessionFactory instead of the SessionFactory class in your module's DAOs.
If you only want to support Platform 2.0 and above then you can continue to use SessionFactory.
The DBSessionFactory class has been introduced in Platform 2.0, 1.11.3, 1.10.2, 1.9.9. It is not available in older releases so to use it you have to bump your module's required version of Platform to either 2.0, 1.11.3, 1.10.2, 1.9.9. For example if your module used to support 1.9.4 and above then you would have to declare <require_version>1.11.3, 1.10.2 - 1.10.*, 1.9.9 - 1.9.*</require_version> in your module's config.xml and use the 1.9.9 version of openmrs-api dependency in your pom.xml. It entails that any implementation that wants to continue to use your module will have to run one of the quoted versions of OpenMRS Platform. An example of changes in a module can be found at https://github.com/openmrs/openmrs-module-htmlformentry/pull/86/files
Any implementation that cannot upgrade to the latest maintenance version of Platform will have to fork your module and create a custom build that declares an aware of dependency on https://github.com/kristopherschmidt/openmrs-module-hibernatecompatibility. It is a module that includes the DbSessionFactory class. The implementation will have to install that module in addition to the forked module. An example of changes required in a forked module can be found at https://github.com/openmrs/openmrs-module-atlas/compare/master...kristopherschmidt:ATLAS-118
For module developers who do not want to require upgrading to the latest maintenance version of the platform, you could use an alternative approach as done by the xforms module at https://github.com/openmrs/openmrs-module-xforms/commit/5d79f327d27777a40ec755a90433e4dc69067e4a
For more information regarding supporting multiple platform versions, take a look at this guide.