Non-functional Enhancements
The service levels offered by modern public clouds will almost always be capable of delivering a quality of service equal or above the level of service an organization might deliver within an on-premises environment. Some of these benefits are automatic (e.g. the durability of storage, automatic database backups) and others will require some level of change to enable the higher service levels (e.g. cross-region data replication).
Storage capacity increase is a very frequent driver for an application to move to cloud, and the public cloud is able to provide virtually unlimited capacity for many different types of storage. However, your application may not be able to take advantage of storage flexibility without some degree of change. If n application is wholly embedded within a VM (including data) then you will be constrained by the maximum VM size - moving to external storage is a small change but will enable greater capacity. If you are using a database, then some managed database services (e.g. Autonomous DB) will offer storage that will automatically extend as you need more.
Adding CPU capacity to an application is also a very common requirements. In many cases, an application will see a performance boost where the legacy hardware is relatively old - the CPUs on the public cloud are more likely to be faster. In addition, public cloud servers generally have modern CPUs with large core densities per server, and so moving to cloud may give greater headroom on a single server.
Adding compute beyond a single server is much more complicated, and for some applications impossible. If your starting point is an entire application on a single server (e.g. web server, application server and database) then it should be possible to split up the layers into different servers, or use native cloud services for one or more layers (e.g. the database service) and this could deliver significantly higher CPU resources. However, if you need to split a service (e.g. the application server) over multiple cloud server, then this is a change from a single-node to a clustered service. Many applications will require significant change to enable clustering, and for some (especially some ISV applications) it may be impossible.
If your middle-tier is stateless, then the switch to a clustered architecture is relatively straightforward - this is then natively supported by many mid-tier application servers (e.g. Websphere, Weblogic, JBoss etc), and you also have to option to move to Kubernetes cluster model.