Annoyingly, java will not let you access a static inner class via a child of the parent one. So, all references to org.apache.poi.hssf.usermodel.HSSFFormulaEvaluator.CellValue will need to be changed to org.apache.poi.ss.usermodel.FormulaEvaluator.CellValue

Annoyingly, java will not let you access a static inner class via a child of the parent one. So, all references to org.apache.poi.hssf.usermodel.HSSFRow.MissingCellPolicy will need to be changed to org.apache.poi.ss.usermodel.Row.MissingCellPolicy

If you have existing HSSF usermodel code that works just fine, and you don't want to use the new OOXML XSSF support, then you probably don't need to. Your existing HSSF only code will continue to work just fine.

However, if you want to be able to work with both HSSF for your .xls files, and also XSSF for .xslx files, then you will need to make some slight tweaks to your code.

The new SS usermodel (org.apache.poi.ss.usermodel) is very heavily based on the old HSSF usermodel (org.apache.poi.hssf.usermodel). The main difference is that the package name and class names have been tweaked to remove HSSF from them. Otherwise, the new SS Usermodel interfaces should provide the same functionality.

Calling the empty HSSFWorkbook remains as the way to create a new, empty Workbook object. To open an existing Worbook, you should now call WorkbookFactory.create(inp).

For all other cases when you would have called a Usermodel constructor, such as 'new HSSFRichTextString()' or 'new HSSFDataFormat', you should instead use a CreationHelper. There's a method on the Workbook to get a CreationHelper, and the CreationHelper will then handle constructing new objects for you.

For all other code, generally change a reference from org.apache.poi.hssf.usermodel.HSSFFoo to a reference to org.apache.poi.ss.usermodel.Foo. Method signatures should otherwise remain the same, and it should all then work for both XSSF and HSSF.