Project Closing

Each Sprint is a project. If stakeholders fund more Sprints, there will be more opportunities for value to be maximized and for product risk to be empirically controlled. A supplier can reasonably be expected to know how much it will cost them to run a Sprint, and as such it may be used as a basic unit for assessing the commercials of product development.

If n Sprints have been purchased, and value has been maximized and/or risk significantly mitigated after n-x Sprints, there could well be diminishing returns after that point. The game would no longer be worth the candle. An agile contract may provide for reimbursement of (say) x-1 Sprints under such circumstances. The supplier then still gets something but the client does not pay the full whack.

There's no one answer.

If the team that did the original design and development of the product is also continuing to maintain the software and/or provide improvements, then perhaps the team will continue using the Scrum framework to manage the continued evolution of the product. Alternatively, the team may inspect and adapt their way of working and determine that Scrum is no longer appropriate and find a way of working that is no longer consistent with the rules of Scrum. It's worth noting that a Scrum Team may evolve their way of working to be "not Scrum" at any time through the inspection and adaptation in the Sprint Retrospective.

If the product has no more work (the Product Backlog is empty) or the customer no longer wishes to fund development, the team can go on to other things. The team could be disbanded. Or perhaps they'll work on another product. Or, if they were contractors, will enter an engagement with a new client. But regardless, they move on.

This is the opening statement from the Scrum Guide's section that describes the Product Backlog.

The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.

Your question is about how to maintain the product after it has been delivered.  Maintaining usually involves fixing bugs, adding new features, modifying features to fit current needs.  All of those are changes "needed to improve the product".  Scrum applies as long as the product is in use.  You do not "close a project" in Scrum.  You retire a product.  You can organize the work in groups of related Product Backlog Items to define a "project" and as such each Product Backlog would be used across many projects.  Projects are not part of the Scrum framework.  The word "project" can only be found once in the Scrum Guide.  It is in the section that describes the Sprint.  Here is the sentence in which it is used. 

Each Sprint may be considered a short project.

I know of many companies that utilize User Stories that will create Epics as containers for a focused effort, such as delivering a new product or new features of an existing product.  That enables them to talk about specific strategic efforts in similar ways that many companies discuss projects. The Epics can be closed but the Product Backlog lives on until the product is removed from the companies offerings.