It is hard to make an existing procedural program into a good OO one (at least if it's of any size). You will probably get some benefit from encapsulation and modularity if you break your program up into packages, but that won't make it OO.

Object oriented programs are not designed around data and operations on that data, no matter whether the operations are separated into modules that only deal with a single kind of data or not. That model (data and procedures that operate on data) is the basis of the procedural model, independent of packaging and data hiding.

Instead, object oriented design models a program as a community of collaborating entities (objects), each with their own responsibility. These objects don't have to have any data at all; they might just provide behavior.

The problem with converting from a procedural program to an OO one is that the problem decomposition happens differently: structured procedural programs are designed by breaking down the overall task into subtasks and introducing data as needed by the subtasks. OO ones are designed starting with object interactions first.

I ran across a good article that discusses this difference from an educational point of view, and suggests that object oriented concepts should be presented before procedural ones. You can find it here: Why Procedural is the Wrong First Paradigm if OOP is the Goal