Freebsd – ports in freebsd jail fetching but not updating

I have never been fully satisfied with the ports system in a large environment -- It always seems like you need to apply some external management to it in order to make it work well.

My best tips (in order of ascending preference, "worst" solution to "best" solution):

If you're building on each host, don't.
If you must, don't do it over NFS with read-write mounts like you describe: You can usually trust the ports to Do The Right Thing and not stomp on the ports tree if you provide alternate work directories, but it's always better to be safe than sorry: Run a local CVS/csup mirror and csup all your hosts from that box, then build locally as you would if they were individual machines.
Yes, I know this means having more disk space on the hosts and an extra step. It's also almost guaranteed to be problem-free.
Caveat: You probably want to sync the package configuration files (rsync or similar) from a designated "configuration host" to ensure consistency on each machine (you can even rsync the whole ports tree if you want, rather than using csup on each node).

Use a Build Host, create packages, and install those.
A much better solution than building on each individual machine: Use a build host to create packages, and point your tools at those packages.
This means keeping a build host around for every architecture you run (or cross-compiling), but it's ultimately nicer for your target machines (no large compile jobs, a guarantee of consistency)

Use a configuration/system management tool.
This is the solution I wound up with -- I build a standard server image and deploy it around my environment using radmind. You can do similar things with Puppet or Chef. This has all the advantages of using a build host (consistency, less load on the individual servers), and adds the benefit of configuration management.

Caveat: This only works really well if your machines are "identical" -- That is you can install the same set of ports on all of them. It can work if you have varying sets of ports, but that substantially increases the administrative overhead.

Disclaimer: I'm the port maintainer for sysutils/radmind. Yeah, I like it that much that I adopted it.

All of this is based on my experience managing various-sized FreeBSD environments (ranging from 1-2 machines to over 100). Configuration/System Management tools that push and maintain a standardized image are really the best way to handle this in my experience.

For what you're describing, "jail migration" is almost certainly the Wrong Solution -- you really want to apply DDoS protection across your whole network, not just a specific host/set of IPs.

More generally, as I said in my comment, Jails don't "migrate" in the way you're describing. Some folks have done creative things with geom_mirror and ggated, but this is more failover than at-will migration, and I would describe the process as "cumbersome" at best.
Live migrations of running virtual machines (either at-will or automatic for resource balancing) is really better left to true hypervisor systems like VMWare and Hyper-V (Linux KVM may be getting there, and one day it might be a project that the FreeBSD Jail folks take on, but Jails are really designed to be process/system isolation -- a chroot on steroids -- rather than a VM you can pick up and move from host to host. Migration is one of those things that takes a lot of programming effort).

Some things I know you can't do are use a "wildcard IP" -- IP addresses are assigned to both the underlying host system and the jail, so migrating requires you to move the IP addresses around. You could use DNS to make the switchover (running both a protected and unprotected copy of the jail and using techniques similar to those in the link I described), but that's guaranteed to have some crossover time (at least the TTL of the record), and is basically asking you to double your hardware & IP space commitment -- probably not feasible unless you charge a lot more for the privilege of having this service (and if you're going to do that and can only give DDoS protection to a portion of your infrastructure you may as well just charge people a lot more to be on the DDoS-protected systems full-time -- it's a much smaller administrative headache).