There is no way, to catch the possible issues for the previous version of IRIS.

The best case scenario is if you automate the build process, for instance with Docker, and test a compile stage on different versions of IRIS. But the ability to successfully compile may not prove that it will work, it would be better to have some unit tests, which will check it.

One more thing, may help, to check it, using the such tool as ObjectScript Quality, can help with checking System's API version. Where you can set the oldest supported version of IRIS, and during the scan, it can check if Methods are available in that particular version.

Implemented it with SQL Procedure

	new $namespace
	set $namespace = "%SYS"
	$$$ThrowOnError(##class(Config.Namespaces).Get(sourceNS, .sourceNSparams))
	$$$ThrowOnError(##class(Config.Namespaces).Get(targetNS, .targetNSparams))
	for kind="Globals", "Routines" {
		$$$ThrowOnError(##class(Config.Databases).Get(sourceNSparams(kind), .sourceDBparams))
		$$$ThrowOnError(##class(Config.Databases).Get(targetNSparams(kind), .targetDBparams))
		set from = sourceDBparams("Directory")
		set to = targetDBparams("Directory")
		set done(to) = "" 
		$$$ThrowOnError(##class(SYS.Database).Copy(from, to, , , 4))

DANGER: Do not use it, made specifically for my case, it may overwrite database

Is it really the reading file taking so much time or using $piece on the line and setting it to global too?

There are various things here that may slow you, even $increment (best to be replaced by i+1)

You can also split the reading file and set it to global by two parts, and use $sortbegin 

Try to run your code with %SYS.MONLBL started, it will help you understand where it spends more time.