Document weekly rate (count and seriousness) of newly detected bugs, fixed bugs, and fixes which failed and were returned back to development for additional fixes. Then you can extrapolate how many would be detected in the week after release, and let managers to decide if it is OK to release this many bugs to production, or longer testing is required to make product more stable.
Compare these rates with rates for previous releases, and with known bugs detected in production after previous releases, so you can show the trends to management.
Remember you cannot "assure" there are no bugs. QA is "Quality assistance": assist management to make best decisions for the business by providing up-to-date info about current status, and trends, of the quality of the product. Sometimes management is willing to accept more risk to release version at certain date, and sometimes is willing to postpone to get better quality. It is business decision, QA just provides inputs for it (as does marketing, production, finance dept etc).
I would never try to convince boss to delay the release. I would note that rate of detecting new bugs is higher that during previous releases, and let him to make the decision.
We work in aviation, and aviators are strong believers for checklists (and acronyms). So we have a "Cutover Readiness Review" (CRR) checklist, where we have all the information comparable with previous cutovers. After release, we have "Release Lessons Learned" where we can add new questions to CRR, to improve the process for next release One of the questions we ask is "what is your gut feeling about the upcoming release", because once in RLL many people noted they had a strange gut feeling about the release which was hard to verbalize (and it was less that stellar success), so - a lesson was learned. :-)